Closed Bug 758823 Opened 12 years ago Closed 12 years ago

configure creates egg-info directories in the source tree

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla18

People

(Reporter: glandium, Assigned: gps)

References

Details

Attachments

(1 file)

This is what is being created during configure. They are create in the source tree :(

other-licenses/simplejson-2.1.1/simplejson.egg-info/
testing/mozbase/manifestdestiny/ManifestDestiny.egg-info/
testing/mozbase/mozinfo/mozinfo.egg-info/
testing/mozbase/mozinstall/mozInstall.egg-info/
testing/mozbase/mozlog/mozlog.egg-info/
testing/mozbase/mozprocess/mozprocess.egg-info/
testing/mozbase/mozprofile/mozprofile.egg-info/
testing/mozbase/mozrunner/mozrunner.egg-info/
Carl: is there a way to prevent this? AFAIK they don't do anything useful.
The egg-info dirs are created by setuptools when a package is installed in-place via "python setup.py develop" (aka "pip install -e"), to allow setuptools/pip to track the metadata about what package and version is installed. It's ok to just remove them after the fact; the only noticeable impact will be that the package will no longer show up in e.g. a "pip freeze" and pip will no longer be able to "pip uninstall" it (although it'll still be importable).

There's no way I know of to prevent them being created in the first place, other than to not do the develop/editable install and instead just do "python setup.py install" (or "pip install" without the "-e"). Unless these packages are actually being modified in-place during the build process, I don't think there's any need to be installing them as develop/editable.
So I can wipe these from my local machine but they'll keep returning?
Carl: I intentionally used "develop" because I do think it will be useful. While we have some third-party modules in the tree (like simplejson), we also have quite a few Mozilla-specific modules, and it seems pretty likely that some developers will wind up in an edit and test cycle. It'd be a lot nicer if they didn't have to refresh the virtualenv every time.
Maybe worth adding to .hgignore?
(In reply to Jeff Hammel [:jhammel] from comment #7)
> Maybe worth adding to .hgignore?

As a temporary fix, sure.  But I think in general it's unfortunate to clutter the srcdir with products of the build.
We also have mozilla specific modules without setup.py. In fact, I suspect most are this way. Are we going to need a setup.py for any such module? Can't we just install them with symbolic links?
The non-setup.py ones will be handled separately, yeah. I need to file a bug on that, but our options are: a) just symlink them into the virtualenv's site-packages dir, or b) stick a .pth file in the site-packages dir containing a path to the directory containing them, which gets it added to sys.path (leaning towards b), since we can install whole dirs of modules that way).
FWIW, the creation of in-situ .egg-info (and similar) files is parallel to the outputting of .pyc files in python, as noted in other bugs.  Ideally, I'd like to see neither of them in the source tree, but also AFAIK these aren't easily preventable (at least without drawbacks)
Well, the pyc files caused havoc a month or so ago; there's certainly a trade-off with keeping those in the source tree.  I hope the downside here isn't quite as bad!
FWIW, I often check egg-info directories into source control even when I don't check in .pyc files, if I am checking in "installed" versions of libraries (i.e., in a vendor library situation).  But if I'm handling source packages I leave them be but add *.egg-info to hgignore.
FWIW, as a workaround, add '*.egg-info' to your .hgignore
We've .hgignored them, seems to be fine for now.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
Patch forthcoming that nukes these. I figured it was easier to reopen this bug then file yet another one.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Pythonistas may scream at this. But, it is exactly what we want:

1) Changes to srcdir don't require virtualenv repopulation (like |python setup.py develop|)
2) No extra crap in the srcdir

I think the only contentious part is removing the entries from the .hgignore and .gitignore files. I think this is a good idea because I maintain that the smaller these files are, the better: we shouldn't be spewing junk in the srcdir and I welcome any chance to purge my tree of things that aren't needed.

Try at http://tbpl.mozilla.org/?tree=Try&rev=0d941ca66e96
Assignee: nobody → gps
Status: REOPENED → ASSIGNED
Attachment #656515 - Flags: review?(ted.mielczarek)
If compiling C extensions, I would probably need to add --inplace to |python setup.py build_ext|. However, the only package we currently have with a C extension is simplejson. And, it looks like its setup.py file has been hacked up to never compile the C extension. So, I think I'll just remove the first line from packages.txt. I won't bother with a new patch.

Also, :sid0 says to ignore the Win64 try failure (pymake issue, I guess).
Comment on attachment 656515 [details] [diff] [review]
Don't create egg-info directories, v1

Review of attachment 656515 [details] [diff] [review]:
-----------------------------------------------------------------

Seems fine.
Attachment #656515 - Flags: review?(ted.mielczarek) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/d034d1924fc7

I added instructions on how to remove egg-info directories to the commit message.
Target Milestone: --- → mozilla18
https://hg.mozilla.org/mozilla-central/rev/d034d1924fc7
Status: ASSIGNED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.