package based on distutils / setuptools metadata, don't attempt to guess

[ronaldoussoren]

Original report by Glyph (Bitbucket: Glyph, GitHub: Glyph).

---

Disk is cheap these days.

While some applications care a great deal about being small, and the optimizations implemented by modulefinder are very useful for that case, in my opinion it is a bad default behavior. It requires the creation of py2app recipes to go along with the already-perfectly-valid distutils metadata about what code to include.

Please consider adding a mode – ideally the default mode – where the entirety of the standard library, and all modules listed in install_requires, and all data_files, are simply included in the app bundle, so that I can use libraries which dynamically load functionality at runtime or expect their data files to be present without having to first write a parallel distribution system for those dependencies.

Thanks!

[ronaldoussoren]

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).

---

I mostly agree and definitely want to add better support for distutils metadata, although mostly because modules that use pkg_resources to get at metadata (such as package versions or entry points) don't work right now.

I don't agree that the size of packaged application isn't important, I've had complaints about the size of applications in the past (although that's mostly due to the size of the interpreter itself and some large libraries).

That said, I do like the idea of including entire distutils packages by default (and using the recipe system and/or configuration) to explicitly remove unnecessary parts. I'm not sure yet if I like doing the same for the stdlib because it would be too easy to pull in too much stuff (such as all of Tkinter and its dependencies).

[ronaldoussoren]

Original comment by Ronald Oussoren (Bitbucket: ronaldoussoren, GitHub: ronaldoussoren).

---

BTW. Getting the distutils package that a module is part of, and which other files are in that package, is non-trivial in general. In particular, I don't think there is a good way to get that information for "develop" installs and for installs that don't use an egg (file or directory) or record file (as used by pip).

[ronaldoussoren]

Original comment by RobertR (Bitbucket: RobertR, GitHub: RobertR).

---

mapping back to distribution name is hard yes, because a distribution has many packages.PEP-426 heads us in a decent direction.

That said, just capturing the current .dist-info directories would allow app use of pkg_resources to get metadata to work. pip record files can be used to find other content to install, yes.

That said, another way to capture what needs installing is to start with a populated virtualenv, and copy the python bits lock stock and barrel.

[ronaldoussoren]

Original comment by Glyph (Bitbucket: Glyph, GitHub: Glyph).

---

This could potentially go a long way to addressing #1 as well :)