[Distutils] command hooks...

[Chris McDonough]

On 05/16/2012 02:55 AM, Tarek Ziadé wrote:
> On 5/16/12 3:58 AM, Chris McDonough wrote:
>> Adding two more (packaging and distutils2) which are similarly
>> semi-documented and which don't even solve the problems that the
>> previous ones do would serve no purpose, and baking them into Python
>> itself will mean they can't evolve in important ways.
>
> Oh, I think I need to answer to this too since you said you wanted to
> help. Packaging is not intended to be similar to setuptools in its
> features.
>
> For instance we won't provide console scripts or entry points. The first
> one because 'script' is the same feature (except there's an indirection
> and I said before we could mimic this)
> The second one because we should build this kind of feature outside the
> stdlib (this is not something most people use, according to the survey I
> did back a few years ago, it's mostly zope/plone/repoze land)

I suspect many people don't really know they're using entry points when 
they are. PasteDeploy configuration files rely heavily on entry points. 
  Those are used in various ways by Pylons, Pyramid, Zope, and 
Turbogears.  (PasteDeploy itself been downloaded almost a million times 
from PyPI.)

I'm fine with needing to depend on an external package to scan for 
entrypoint-like-things registered as the result of the installation of a 
distribution.  But there will need to be a way to register 
entrypoint-like things (along the lines of arbitrary egg-info metadata) 
as the result of distribution installation using pysetup.  Maybe that 
already exists.

> I'd suggest you list what you can't do with "packaging" today and we
> work through that list to point which features are missing and should be
> developed *outside* the standard lib, and which ones are in "packaging"
> or should be

I can try.

> IOW: packaging should only be the common basis and provide a basic
> installer - not a full fledge tool you can use to replace the most
> advanced setuptools features. And we want it pluggable enough so people
> can build pluggable features on the top of it, like Eric explained earlier
>
> Does that make sense ?

I'd like to say it does, but I'm afraid it does not.

I can see shipping both machinery and a full-fledged installer that 
handles all the use cases of existing installers.  I can also see 
shipping just machinery and no installer at all.

But I can't really see shipping both machinery and an installer that we 
know doesn't service use cases that existing installers already do.  At 
least I can't see doing that in order to service an external shipping 
deadline.

- C