-
Notifications
You must be signed in to change notification settings - Fork 706
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Requirements from underscored extras are accidentally included as package dependencies #6279
Comments
Thanks for the report. Do you know if that's standards compliant? (I kind of presume not) |
@zanieb I suppose it is not standard: https://packaging.python.org/en/latest/specifications/core-metadata/#provides-extra-multiple-use Maybe the whole section can be ignored instead of that one line? pip-compile just ignores whole requires section of this underscored extras. Do you think there is any other way how to add marker/anchor/fragment for dependencies? e.g. our setup.cfg looks something like this
We don't want to expose the |
Interesting. Thanks for the details. We'll need to chat about this as a team. |
Hm. "ignored" is kind of ambiguous. |
Does this happen with the latest version of |
@zanieb Yes, we use
|
Just confirming that this a bug on our end. |
Well, I guess it's a bit nuanced. Those are technically invalid extra names, and so the spec says we "should" ignore them (per @zanieb's comment above), which just means those dependencies should never be enabled. |
But normalizing the |
@charliermarsh I think it is not normalizing. In
and they get it into main requirements of the package - next to these
The wheel file I attached brings me some idea how the |
To clarify, you want You should try running with |
Yes, for this case
|
Is there any way you can create a small reproduction that I can run locally? |
I created simple local package via |
Awesome, thanks so much. |
Looking at the minimal example, I guess this is a bug in uv because uv is resolving for an extra that was never requested? But this concept of a "private" extra certainly isn't within the spec, it’s not clear to me if you are expecting any behaviour from pip / pip-tools / setuptools right now, but if it has an invalid name according to the spec, it might just break one day. For "private" extras behaviour you could have in an somewhat officially supported way, one thing you can do is use a custom build hook (with Hatch or other backends) and specify which extras you want available for editable installs and which extras you want available for the published package, e.g. apache-airflow does this with their |
Yeah I generally agree -- there's some uv bug here, but those extras are also not compliant. |
I think what's happening here is that we fail to parse |
I will try to invert that. |
Yeah, I was gonna try just fixing this case of an invalid extra. |
Honestly it would be easier to do what setuptools does and cast it to |
You already do some "fix ups" to versions and requirements which don't conform to standards, for uv's use case of being drop in replacement, makes sense to do it for invalid extas 🙃 |
Hello,
I would like to ask/report one issue with
uv pip compile
when using "private" extras (underscored extras).It happens on new uv
0.3.0
and also the previous one0.2.37
on linux mint with python 3.9 in venv.My humble tip that causing this issue is that
our-internal-package
has some underscored extra_sqlalchemy
that the metadata parser just skips and takes all _sqlalchemy's dependencies as the base deps for the package (because it was parsing the section before):METADATA taken from wheel of our-internal-package
requirements.in for our app
generated requrements.txt
verbose logs with removed warnings about skipping files
edit 2024-08-21: enclosed uv logs to code block for better readability
The text was updated successfully, but these errors were encountered: