Open jbw-vtl opened 1 month ago
Per your second question: if we don't have an available wheel for the current platform, but do have a matching source distribution, we read the metadata from the wheel to avoid having to build the project from source.
Okay understood, that makes sense.
Will stay tuned for the pip download
support then for a more proper solution.
Oh sorry, I was just answering your second question. We do know the list of compatible URLs, so in theory we could write them to the output file.
having the compatible artifact url as an optional annotation in the output would make my life a lot easier.
However shouldn't be prioritized too much, for now have built around the debug logs, replacing the logged artifact url with source distribution for packages matching a source distribution.
I.e. DEBUG Selecting: cx-oracle==8.3.0 (cx_Oracle-8.3.0.tar.gz)
Definitely not the best solution and building on top of debug logs feels a bit scary, but will do for now.
Did actually run in an issue with the debug logs containing different versions for the same artifact, which means I can't really rely on the logs.
Quite keen on getting the option to return the compatible urls somehow
Hi All,
First of all, thank you very much for developing uv, it has already had a large impact on our CI / CD performance and is slowly growing in adoption across our developers.
To transform our last pip dependent internal process, we are looking to get access to either the raw artifacts (.whl / .tar.gz) or the url to the resources in the index, to then download them ourselves. This would be solved by implementing
pip download
, I know there's an existing issue #3163 that tracks this request.In the meantime, wondering whether we could somehow get access to the artifact urls to hack together our own script. Noticed that when running
uv pip compile requirements.in -v
, it does output the resources used which could be parsed. This seems to work pretty well, see a an example below for whats working as expected.Working as expected
Output (path and repo details hidden)
Using the above output, its fairly trivial to extract the links to all the .whl artifacts used. So far so good.
Not working as expected
When doing the same for package without a matching whl file (i.e. cx-oracle==8.3.0, which is deprecated and has no wheels for 3.11), the output seems to select the wrong artifact. The compilation is valid as there exists a source distribution, however would expect to see the source distro in the
Found refresh response for: ...
log. How comeuv
is even checking the manylinux wheel in the first place + the wheel is for 3.10? I know this is debug output, however something seems to be going wrong here. Is it possible the debug log is simply outputting the wrong url?Any help is greatly appreciated.
cx-oracle 8.3.0 artifacts in our repo![image](https://github.com/user-attachments/assets/51686246-e3b6-4ccd-914f-992e132d5d41)