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. |
zanieb
added
the
compatibility
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 compilewhen using "private" extras (underscored extras).It happens on new uv
0.3.0and also the previous one0.2.37on linux mint with python 3.9 in venv.My humble tip that causing this issue is that
our-internal-packagehas some underscored extra_sqlalchemythat 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: