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

Installing, Building a package - generates unnecessary files? .egg-info/ build/ #4198

Open
VladimirFokow opened this issue Jan 31, 2024 Discussed in #4197 · 2 comments
Open

Comments

@VladimirFokow
Copy link
Contributor

VladimirFokow commented Jan 31, 2024

Discussed in #4197

See the discussion - it has several references to people having this issue (including an upvoted stackoverflow question that has the old api: python setup.py sdist)

The issue #1347 dealt with the same problem but with the now deprecated api. The api has changed but the issue remains. The current issue is concerned with pip install ., pip install -e ., python -m build (and possibly, other commands which lead to this behavior which I could just miss now).


Description of the issue:

Assuming the src-layout:

  • Each of pip install -e ., pip install . and python -m build create "src/PACKAGE_NAME.egg-info/"

    If we delete this directory - the installed package continues to be importable and seems to work fine.

  • In addition, pip install . also creates "build/"

    If we delete this directory - the package also works fine.

These auto-generated folders seem completely unnecessary, yet they pollute the source code repository, and not all beginner users would know how to best deal with them.


Suggested solutions:

  1. At the very least, this behavior should be acknowledged in the Docs, and there should be advice to add the appropriate patterns for each command to .gitignore, e.g.: *.egg-info/, build/, dist/ -- done

  2. Moreover, this issue:

  • needs investigation of the origins of this mechanism; is this behavior actually needed for something, or it is truly a "historical artifact nobody thought of addressing" and should be cleaned up.
  • if it's needed and should stay - then it definitely should be described in the documentation: good introduction, rationale, as well as advice and a good example how to deal with it, or how people usually deal with it.
@VladimirFokow VladimirFokow changed the title Why not auto-delete "src/PACKAGE_NAME.egg-info/" and "build/" Installing / Building a package - generates unnecessary files? Jan 31, 2024
@VladimirFokow VladimirFokow changed the title Installing / Building a package - generates unnecessary files? Installing / Building a package - generates unnecessary files? .egg-info/ dist/ Jan 31, 2024
@VladimirFokow VladimirFokow changed the title Installing / Building a package - generates unnecessary files? .egg-info/ dist/ Installing, Building a package - generates unnecessary files? .egg-info/ dist/ Jan 31, 2024
@VladimirFokow VladimirFokow changed the title Installing, Building a package - generates unnecessary files? .egg-info/ dist/ Installing, Building a package - generates unnecessary files? .egg-info/ build/ Jan 31, 2024
@abravalheri
Copy link
Contributor

Hi @VladimirFokow please note that things are not very simple when it comes to .egg-info.
The .egg-info folders contain entry_points.txt, which in turn is used by importlib.metadata.

Packages may need to rely on that mechanism to bootstrap plugins during build time. Setuptools itself currently uses that mechanism.

Regarding your comments:

Suggested solutions:

  1. At the very least, this behavior should be acknowledged in the Docs, and there should be advice to add the appropriate patterns for each command to .gitignore, e.g.: *.egg-info/, build/, dist/
  2. Moreover, this issue:
  • needs investigation of the origins of this mechanism; is this behavior actually needed for something, or it is truly a "historical artifact nobody thought of addressing" and should be cleaned up.
  • if it's needed and should stay - then it definitely should be described in the documentation: good introduction, rationale, as well as advice and a good example how to deal with it, or how people usually deal with it.

For this we need all the help we can get. Please feel free to proceed with the investigation and/or submit pull requests (we can iteratively find what is the best wording for the docs, but in general it is good to assume that there is no clear cut recommendation that will fit everyone, and that different workflows/usages will entail different "good practices").

@VladimirFokow
Copy link
Contributor Author

  • this comment describes examples where these files would be useful

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

No branches or pull requests

2 participants