You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TST/DEP: circular dependency with astropy-asdf makes lowest graph resolution unworkable #18992
note that bumping asdf-astropy>=0.8 is a possible workaround, but as noted in the upstream issue, I believe this is a fragile hack rather than a solution.
Turns out, this isn't a bug in uv as I previously assumed. An old version of astropy is retrieved from PyPI because tox+tox-uv installs dependencies first, and as a separate step, before installing the project itself. In this context, uv's behavior is indeed correct. I'm now exploring ways I can work within existing tox behavior1, and it looks difficult as well:
tox exposes a install_command option, but it's already overriden by the tox-uv plugin, so I can't really customize it without changing tox-uv itself
the install_command is dynamically computed to include options from {opts}, but this doesn't seem like a public interface, more like an implementation detail for very narrowly scoped options like pip_pre, so I don't think I can use it either
I tried adding a constraint on astropy itself in tool.uv.constraint-dependencies but that won't work because uv recognizes astropy as the project and cannot apply constraints to it (which seems like a very reasonable and intentional limitation)
The only solution I'm seeing right now (other than dropping support for asdf-astropy, which of course wouldn't be acceptable), is to bump our lower bound on asdf-astropy to >=0.7, the oldest version whose lower bound on astropy (>=5.2.0) has wheels for Python 3.11, our current oldest supported Python. Clearly this is a mouthful, a fragile solution, and to some extent, purely a hack around tox's implementation details. As a last resort, I'll propose it nonetheless, together with this explanation, and see what others think.
Footnotes
for the record, I feel like it's needlessly complex, and in this instance, it is making my work more difficult and really not playing its role as a dev helper tool. ↩
Activity
oldestdeps#18782neutrinoceros commentedon Nov 27, 2025
Turns out, this isn't a bug in uv as I previously assumed. An old version of astropy is retrieved from PyPI because tox+tox-uv installs dependencies first, and as a separate step, before installing the project itself. In this context, uv's behavior is indeed correct. I'm now exploring ways I can work within existing tox behavior1, and it looks difficult as well:
install_commandoption, but it's already overriden by thetox-uvplugin, so I can't really customize it without changingtox-uvitselfinstall_commandis dynamically computed to include options from{opts}, but this doesn't seem like a public interface, more like an implementation detail for very narrowly scoped options likepip_pre, so I don't think I can use it eithertool.uv.constraint-dependenciesbut that won't work because uv recognizesastropyas the project and cannot apply constraints to it (which seems like a very reasonable and intentional limitation)The only solution I'm seeing right now (other than dropping support for
asdf-astropy, which of course wouldn't be acceptable), is to bump our lower bound onasdf-astropyto>=0.7, the oldest version whose lower bound on astropy (>=5.2.0) has wheels for Python 3.11, our current oldest supported Python. Clearly this is a mouthful, a fragile solution, and to some extent, purely a hack aroundtox's implementation details. As a last resort, I'll propose it nonetheless, together with this explanation, and see what others think.Footnotes
for the record, I feel like it's needlessly complex, and in this instance, it is making my work more difficult and really not playing its role as a dev helper tool. ↩