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.

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

Clarify zip_safe=False recommendation for PEP 561 #8802

Closed
bhrutledge opened this issue May 12, 2020 · 8 comments
Closed

Clarify zip_safe=False recommendation for PEP 561 #8802

bhrutledge opened this issue May 12, 2020 · 8 comments

Comments

@bhrutledge
Copy link

In pypa/twine#618, I'm adding py.typed so that Twine's type annotations are recognized when it's used as an installed package. I've set zip_safe=False as suggested by the mypy docs:

If you use setuptools, you must pass the option zip_safe=False to setup(), or mypy will not be able to find the installed package.

However, one of the other maintainers has requested removing this: pypa/twine#618 (comment)

The only references I've found to zip_safe in the mypy repo are:

I've done some cursory testing without setting zip_safe, including using pip install -e path/to/twine, and it doesn't seem to be necessary. However, the note quoted above seems unequivocal. Is it still accurate? Could it be expanded?

Caveat: I've only skimmed the issues above, and am far from an expert on the various use cases of setuptools, esp. editable installs.

@ethanhs
Copy link
Collaborator

ethanhs commented May 12, 2020

Hi! Yeah this is a weirder edge of setuptools. For mypy to work, it needs to be able to read files off the disk, and it currently won't unzip eggs (this is something that mypy could support, but makes our already very complicated module searching code even more complicated). My understanding is that in some cases, such as running python3 setup.py install, if your package doesn't opt out, it will be installed as an egg and things won't work. In the linked issue I likely misremembered, as pip install -e just makes an egg link, which I added support for.

E: also, I'm a bit surprised that Jason said the flag shouldn't be passed, because when I talked to him at PyCon a couple of years back, he seemed to indicate that packaging tools are moving away from doing egg installs.

@bhrutledge
Copy link
Author

Thanks, @ethanhs. What do you think about adding this sort of detail to the mypy docs?

Also, @jaraco, is there anything you'd like to add?

@ethanhs
Copy link
Collaborator

ethanhs commented May 13, 2020

What do you think about adding this sort of detail to the mypy docs?

Yeah that seems like a good idea. I'd be happy to review a PR if you'd like to make one.

@jaraco
Copy link
Member

jaraco commented May 13, 2020

Eggs are deprecated. As is setup.py install. If users are using that, it's their responsibility to install with --zip-safe=false or similar. But for projects that are not reliant on deprecated installer techniques, it should be possible for them to omit this cruft and instead rely on best practices when running mypy. By recommending zip_safe=False, it signals support for a deprecated workflow even if that workflow is unsupported. For that reason, I would strongly recommend against recommending use of it as a matter of course. You may want to include a note that if the package is installed using legacy behaviors (setup.py install), that one may want to set zip_safe=False somehow... but I would strongly discourage dragging this historical artifact into modern packages.

@ethanhs
Copy link
Collaborator

ethanhs commented May 14, 2020

Eggs are deprecated. As is setup.py install

Hm, unfortunately a lot of people still use setup.py install. So I mostly have written the advisory to add this as a defensive measure to prevent someone from hitting a bad interaction. And its a lot easier to get packagers to do something "the right way" than get every user of every package to do so. I do think the docs could explain more about this.

ap-- added a commit to Bayer-Group/paquo that referenced this issue Aug 3, 2020
zip_safe=False was added because of a mypy recommendation when
packinging 'py.typed'. But is seems this is outdated and for the
case where `setup.py install` needs to be supported.

See: python/mypy#8802 (comment)
@YodaEmbedding
Copy link

Eggs are deprecated. As is setup.py install.

What's the recommended alternative?

@ethanhs
Copy link
Collaborator

ethanhs commented Oct 4, 2020

@YodaEmbedding most people probably should be using pip install . and wheels. The only real use left for eggs is setup.py develo (but you should probably use pip install -e . anyway).

jbeezley added a commit to kitware-resonant/django-composed-configuration that referenced this issue Dec 14, 2020
I looked into this and found this comment:
python/mypy#8802 (comment)

Also, even if using `setup.py install` setuptools will automatically add
the flag if it detects any package data present.

https://setuptools.readthedocs.io/en/latest/userguide/miscellaneous.html#setting-the-zip-safe-flag
jbeezley added a commit to kitware-resonant/django-composed-configuration that referenced this issue Dec 14, 2020
I looked into this and found this comment:
python/mypy#8802 (comment)

Also, even if using `setup.py install` setuptools will automatically add
the flag if it detects any package data present.

https://setuptools.readthedocs.io/en/latest/userguide/miscellaneous.html#setting-the-zip-safe-flag
lalten added a commit to lalten/openhtf that referenced this issue Apr 24, 2021
This commit adds a py.typed file, which marks the package as having type information available.
For more information, see  https://mypy.readthedocs.io/en/stable/installed_packages.html#making-pep-561-compatible-packages

The zip_safe seems to be [still necessary](encode/httpx#193 (reference)),
even though it is [deprecated](python/mypy#8802).
akkornel added a commit to stanford-rc/mais-apis-python that referenced this issue Jul 5, 2021
All of the Python code in this package is fully typed.  That's great
(and essential), but typechecking tools like MyPy weren't able to say if
it was OK to use the typing info in these modules.

The way for indicating this is PIP 561
(https://www.python.org/dev/peps/pep-0561/), which for us means putting
a `py.typed` file at the root of each module we provide.  The file can
be empty; it's the presence of the file that provides the signal to
type-checkers.

This also modifies `MANIFEST.in` to ensure the `py.typed` files are
bundled into distributions.

Finally, `zip_safe` is disabled in `setup.cfg`.  This ensures that,
when someone tries to install this software using `setup.py install`, it
will not attempt to produce an egg file.  This is needed because MyPy
does not look inside egg files when searching for module type
information (see python/mypy#8802 for more
details).  People shouldn't be using `setup.py` directly anymore anyway,
packages should be installed using `pip` (for example, `pip install
stanford-mais`, or `pip install .` if installing from a Git clone).

Closes: #1
@hauntsaninja
Copy link
Collaborator

python setup.py install is basically dead; this no longer appears in mypy docs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants