Skip to content
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.

Sign up for GitHub

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

Jump to bottom

uv pip compile adds setuptools (and pip) to requirements.txt #1353

Closed
ThiefMaster opened this issue Feb 15, 2024 · 7 comments
Closed

uv pip compile adds setuptools (and pip) to requirements.txt #1353

ThiefMaster opened this issue Feb 15, 2024 · 7 comments
Labels
compatibility Compatibility with a specification or another tool wontfix This will not be worked on

Comments

@ThiefMaster
Copy link

pip-compile considers dependencies on setuptools (and pip) unsafe and mentions this at the end of the generated file:

# The following packages are considered to be unsafe in a requirements file:
# pip
# setuptools

or

# The following packages are considered to be unsafe in a requirements file:
# setuptools

When using uv pip compile, this is not the case and I get pip added to the requirements.txt (the pip dep is coming from pip-tools and setuptools from packages like babel, pycountry and pip-tools). But both are packages that you generally never want in a requirements.txt (except maybe in VERY specific circumstances - and in those case you probably want to vendor the versions you require instead of having them as package dependencies).
@ThiefMaster ThiefMaster changed the title uv pip compile adds setuptools to requirements.txt uv pip compile adds setuptools (and pip) to requirements.txt Feb 15, 2024
@charliermarsh charliermarsh added the compatibility Compatibility with a specification or another tool label Feb 15, 2024
@juftin
Copy link

juftin commented Feb 21, 2024 •
edited
Loading

FWIW, --allow-unsafe is becoming the default in the next major release of pip-compile: https://pip-tools.readthedocs.io/en/stable/#deprecations

In the next major release, the --allow-unsafe behavior will be enabled by default (jazzband/pip-tools#989). Use --no-allow-unsafe to keep the old behavior. It is recommended to pass --allow-unsafe now to adapt to the upcoming change.

@zanieb
Copy link
Member

zanieb commented Feb 21, 2024 •
edited
Loading

Thanks for the additional context. If pip-compile is moving towards just including these by default perhaps we should continue to do so? It's more safe for us since we don't rely on these packages.

@charliermarsh
Copy link
Member

(We do already "include" these by default, unless I'm misunderstanding your comment.)

@zanieb
Copy link
Member

zanieb commented Feb 21, 2024

(edited to clarify)

@zanieb zanieb mentioned this issue Feb 21, 2024
Merged
@hauntsaninja
Copy link
Contributor

hauntsaninja commented Feb 21, 2024 •
edited
Loading

In my opinion, uv has the right default behaviour, and soon pip-compile will have the right default behaviour too. If I were uv, I would implement #1415 to let people do what they need to, and not change this. (Especially since if you are using uv, I think you have less of a need to mark pip and setuptools as unsafe)

@charliermarsh
Copy link
Member

Yeah, agreed.

@zanieb zanieb added the wontfix This will not be worked on label Feb 21, 2024
@hauntsaninja hauntsaninja mentioned this issue Feb 21, 2024
Closed
@charliermarsh
Copy link
Member

Closing as "working as intended".

toofar added a commit to qutebrowser/qutebrowser that referenced this issue Aug 10, 2024
@toofar
Exclude setuptools from pip-compile output
62e31e0 
This is to match the `pip freeze` requirements compilation method. It's
not clear to me if we actually want this behaviour or not.

If seems `pip freeze` will exclude dependencies of itself: https://pip.pypa.io/en/stable/cli/pip_freeze/#cmdoption-all
Even if there are other packages installed that depend on those
dependencies.

`uv pip compile`, and now the original `pip-compile` both have decided
to include setuptools in generated requirements files:

    astral-sh/uv#1353
    jazzband/pip-tools#989 (comment)

So I'm not sure if we have a reason for going against this here or if
they were just being excluded because that's what pip freeze does.

Hopefully we can drop this commit and use the default behaviour in the
future. For now when I'm trying to provide the new backend it's here to
make the diff of generated files more precise.

This message prefix to identify a pip compile comment was taken from
these examples:

    # The following packages were excluded from the output:
    # setuptool

    # The following packages are considered to be unsafe in a requirements file:
    # setuptools==41.4.0        # via protobuf
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Aug 10, 2024
@toofar
Exclude setuptools from pip-compile output
d730aaa 
This is to match the `pip freeze` requirements compilation method. It's
not clear to me if we actually want this behaviour or not.

If seems `pip freeze` will exclude dependencies of itself: https://pip.pypa.io/en/stable/cli/pip_freeze/#cmdoption-all
Even if there are other packages installed that depend on those
dependencies.

`uv pip compile`, and now the original `pip-compile` both have decided
to include setuptools in generated requirements files:

    astral-sh/uv#1353
    jazzband/pip-tools#989 (comment)

So I'm not sure if we have a reason for going against this here or if
they were just being excluded because that's what pip freeze does.

Hopefully we can drop this commit and use the default behaviour in the
future. For now when I'm trying to provide the new backend it's here to
make the diff of generated files more precise.

This message prefix to identify a pip compile comment was taken from
these examples:

    # The following packages were excluded from the output:
    # setuptool

    # The following packages are considered to be unsafe in a requirements file:
    # setuptools==41.4.0        # via protobuf
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Aug 12, 2024
@toofar
Exclude setuptools from pip-compile output
7875792 
This is to match the `pip freeze` requirements compilation method. It's
not clear to me if we actually want this behaviour or not.

If seems `pip freeze` will exclude dependencies of itself: https://pip.pypa.io/en/stable/cli/pip_freeze/#cmdoption-all
Even if there are other packages installed that depend on those
dependencies.

`uv pip compile`, and now the original `pip-compile` both have decided
to include setuptools in generated requirements files:

    astral-sh/uv#1353
    jazzband/pip-tools#989 (comment)

So I'm not sure if we have a reason for going against this here or if
they were just being excluded because that's what pip freeze does.

Hopefully we can drop this commit and use the default behaviour in the
future. For now when I'm trying to provide the new backend it's here to
make the diff of generated files more precise.

This message prefix to identify a pip compile comment was taken from
these examples:

    # The following packages were excluded from the output:
    # setuptool

    # The following packages are considered to be unsafe in a requirements file:
    # setuptools==41.4.0        # via protobuf
This was referenced Aug 18, 2024
Merged
Open
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Sep 7, 2024
@toofar
Exclude setuptools from pip-compile output
bfdb373 
This is to match the `pip freeze` requirements compilation method. It's
not clear to me if we actually want this behaviour or not.

If seems `pip freeze` will exclude dependencies of itself: https://pip.pypa.io/en/stable/cli/pip_freeze/#cmdoption-all
Even if there are other packages installed that depend on those
dependencies.

`uv pip compile`, and now the original `pip-compile` both have decided
to include setuptools in generated requirements files:

    astral-sh/uv#1353
    jazzband/pip-tools#989 (comment)

So I'm not sure if we have a reason for going against this here or if
they were just being excluded because that's what pip freeze does.

Hopefully we can drop this commit and use the default behaviour in the
future. For now when I'm trying to provide the new backend it's here to
make the diff of generated files more precise.

This message prefix to identify a pip compile comment was taken from
these examples:

    # The following packages were excluded from the output:
    # setuptool

    # The following packages are considered to be unsafe in a requirements file:
    # setuptools==41.4.0        # via protobuf
toofar added a commit to qutebrowser/qutebrowser that referenced this issue Sep 18, 2024
@toofar
Exclude setuptools from pip-compile output
a4ca2f9 
This is to match the `pip freeze` requirements compilation method. It's
not clear to me if we actually want this behaviour or not.

If seems `pip freeze` will exclude dependencies of itself: https://pip.pypa.io/en/stable/cli/pip_freeze/#cmdoption-all
Even if there are other packages installed that depend on those
dependencies.

`uv pip compile`, and now the original `pip-compile` both have decided
to include setuptools in generated requirements files:

    astral-sh/uv#1353
    jazzband/pip-tools#989 (comment)

So I'm not sure if we have a reason for going against this here or if
they were just being excluded because that's what pip freeze does.

Hopefully we can drop this commit and use the default behaviour in the
future. For now when I'm trying to provide the new backend it's here to
make the diff of generated files more precise.

This message prefix to identify a pip compile comment was taken from
these examples:

    # The following packages were excluded from the output:
    # setuptool

    # The following packages are considered to be unsafe in a requirements file:
    # setuptools==41.4.0        # via protobuf
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
compatibility Compatibility with a specification or another tool wontfix This will not be worked on
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@ThiefMaster @charliermarsh @zanieb @hauntsaninja @juftin