[Distutils] command hooks...

[Tarek Ziadé]

On 5/16/12 6:26 PM, Chris McDonough wrote:
> 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.)

yes.

on a side note: The PyPI stats numbers are biased for many libraries 
because they are artificially increased by all the buildouts and Jenkins 
and Travis-CI calls out there.
IOW: if a server downloads 100 times a day "PasteDeploy" because someone 
did not set a cache, does it make it 100 times more popular ?
Same goes for any library that's a core part of the non-monolithic 
frameworks out there.


>
> 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.
we want to make the dist-info  (see PEP 376) structure a directory where 
you can drop anything, so you can have arbitrary metadata. Right now, 
entry_points.txt is copied over in that directory by pysetup.

the new setup.cfg file allows you to define extra metadata as well, and 
what's awesome: we want to publish that static file to PyPI so tools can 
browse it !

=> http://docs.python.org/dev/packaging/setupcfg.html#extensibility

>> 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. 

So what about this suggestion:

let's make this goal : pysetup should be able to install Pyramid 
(without [extras] sorry, we can live without it) - with a few 
adaptations in a branch if needed.

if we can make it work before 3.3rc1, great. If we fail we remove the 
installer part of packaging and move it to an external project

That's just a suggestion, I'll defer the decision to Eric because while 
I can help around, I don't have the time, neither the motivation to do 
packaging work these days.

But we have to hurry up - and check with Guido if he's ok with those 
decisions.

Cheers
Tarek

>
> - C
> _______________________________________________
> Distutils-SIG maillist  -  Distutils-SIG at python.org
> http://mail.python.org/mailman/listinfo/distutils-sig