One Package Per Project
I think that, going forward, Python packaging tools (not installation tools; they should remain as they are, for backwards compatibility) should move to supporting only One Package Per Project. And, each project should have the same name as the package inside. In the future, people should have to download an old copy of distutils deliberately if they want to build projects with several packages inside; we should stop releasing tools that support or encourage it. 1. It is easier on developers who want to "import escher" to know that they can simply list "escher" as a dependency instead of having to guess whether it's "Escher" or "EscherProject" or whether it's part of a larger "lithographers" project or whether, heaven forbid, the author decided to redundantly call the project "pyescher". 2. This practice would make PyPI's name make actual sense. It actually claims to be (you can check the site!) the "Python *Package* Index" whereas in fact it's currently nothing of the sort! It's really an index of "projects" that might have zero, one, or several packages inside of them. We should move all projects towards the good behavior of the ones that already name themselves after the single package that they contain. 3. I think the whole idea of putting several packages in a project was useful back when dependencies didn't exist. It made sense, in ancient days, for "ZODB" to include "transaction" because there was no other way to make sure they got installed together. But now that dependencies are possible, there is no longer a need for multiple- package project that outweights the costs involved. 4. The current scheme makes it impossible to choose a "safe" package name when creating and registering a new package. Just because there's no "escher" *project* when you look at PyPI doesn't mean that some project doesn't have an "escher" package hidden inside. You could choose a package name, distribute your product, and only find out later that your users cannot install both your product and another product simultaneously because the other product was, in fact, already using that package name but without your knowing it. -- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Brandon Craig Rhodes wrote:
I think that, going forward, Python packaging tools (not installation tools; they should remain as they are, for backwards compatibility) should move to supporting only One Package Per Project. And, each project should have the same name as the package inside. In the future, people should have to download an old copy of distutils deliberately if they want to build projects with several packages inside; we should stop releasing tools that support or encourage it.
1. It is easier on developers who want to "import escher" to know that they can simply list "escher" as a dependency instead of having to guess whether it's "Escher" or "EscherProject" or whether it's part of a larger "lithographers" project or whether, heaven forbid, the author decided to redundantly call the project "pyescher".
2. This practice would make PyPI's name make actual sense. It actually claims to be (you can check the site!) the "Python *Package* Index" whereas in fact it's currently nothing of the sort! It's really an index of "projects" that might have zero, one, or several packages inside of them. We should move all projects towards the good behavior of the ones that already name themselves after the single package that they contain.
3. I think the whole idea of putting several packages in a project was useful back when dependencies didn't exist. It made sense, in ancient days, for "ZODB" to include "transaction" because there was no other way to make sure they got installed together. But now that dependencies are possible, there is no longer a need for multiple- package project that outweights the costs involved.
4. The current scheme makes it impossible to choose a "safe" package name when creating and registering a new package. Just because there's no "escher" *project* when you look at PyPI doesn't mean that some project doesn't have an "escher" package hidden inside. You could choose a package name, distribute your product, and only find out later that your users cannot install both your pr-duct and another product simultaneously because the other product was, in fact, already using that package name but without your knowing it.
- -1. Infeasible, AFAICT, even if I agreed with the goals: - - While trying out new bits of software, the developer is already going to know the PyPI name: that is how she found the package in the first place (most likely). - - There are scores of "projects" extant whose names don't match the single, top-level package they contain, and will be for the foreseeable future. - - There are a number of "projects" which don't ship any top-level package at all, but contain one or more modules. - - "Bundling" packages together might actually happen more often in the future (e.g., to ease installation onto the GAE, or to solve other deployment problems (e.g., needing to install without network access). - - Namespace packages were invented to reduce the problem you raise in #4 to competition for the top-level name only. Because those names are usually about "identity" of the releasing organization, rather than functionality of the software being released, it has, in fact, worked. Current status which affects some of your concerns: - - PEP 314 added a 'Provides' field to PKG-INFO; that field is supposed to name modules and packages included. That PEP also added 'Requires' and 'Obsoletes' fields, which are mostly unused. This information is available on a per-package basis from PyPI at the moment, but see below. - - PEP 345 will add 'Provides-Dist', 'Requires-Dist', and 'Obsoletes-Dist' fields to PKG-INFO, where the values are going to be "project" names and versions. - - We expect to be able to build index files which can be downloaded (e.g., from PyPI or another index) which will make it easier to find and resolve dependency graphs a priori,. This file will be similar to the index files which yum and apt download from indexes, and could support queries like those done by 'apt-cache query' or 'yum search', which should make it easier to find the projects which 'Provide' a given package name, as well Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ+wwG+gerLs4ltQ4RArCKAJ46IYoIr5WvFwRCeC5yxyXyd4M/6wCeL/2d xAYukhM+nSNV1gpHUp4XOdc= =oEqs -----END PGP SIGNATURE-----
Hi Brandon, It sounds like a nice idea, in terms of simplifying things, but it worries me what "evil" code would have to be written to enforce it. My simplistic understunding of python packaging is that there are: - internal packages and user packages.. divided into: - site-packages - registered site-packages - packages located elsewhere outside site-packages but 'registered' via a .pth in site-packages - project packages - project sub-packages I would describe what you are talking about as project sub-packages. If they aren't registered.. in site-packages.. then it doesn't really make any difference how many there are. Or what they are called... What we need is restructuring sure... But what seems to be needed is clearer thought around the whole package registration system. I'm all for simplification.. On Fri, 01 May 2009 10:20:07 -0400, Brandon Craig Rhodes <brandon@rhodesmill.org> wrote:
I think that, going forward, Python packaging tools (not installation tools; they should remain as they are, for backwards compatibility) should move to supporting only One Package Per Project. And, each project should have the same name as the package inside. In the future, people should have to download an old copy of distutils deliberately if they want to build projects with several packages inside; we should stop releasing tools that support or encourage it.
1. It is easier on developers who want to "import escher" to know that they can simply list "escher" as a dependency instead of having to guess whether it's "Escher" or "EscherProject" or whether it's part of a larger "lithographers" project or whether, heaven forbid, the author decided to redundantly call the project "pyescher".
2. This practice would make PyPI's name make actual sense. It actually claims to be (you can check the site!) the "Python *Package* Index" whereas in fact it's currently nothing of the sort! It's really an index of "projects" that might have zero, one, or several packages inside of them. We should move all projects towards the good behavior of the ones that already name themselves after the single package that they contain.
3. I think the whole idea of putting several packages in a project was useful back when dependencies didn't exist. It made sense, in ancient days, for "ZODB" to include "transaction" because there was no other way to make sure they got installed together. But now that dependencies are possible, there is no longer a need for multiple- package project that outweights the costs involved.
4. The current scheme makes it impossible to choose a "safe" package name when creating and registering a new package. Just because there's no "escher" *project* when you look at PyPI doesn't mean that some project doesn't have an "escher" package hidden inside. You could choose a package name, distribute your product, and only find out later that your users cannot install both your product and another product simultaneously because the other product was, in fact, already using that package name but without your knowing it.
-- Brandon Craig Rhodes brandon@rhodesmill.org http://rhodesmill.org/brandon _______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
participants (3)
-
Brandon Craig Rhodes -
David Lyon -
Tres Seaver