[Distutils] command hooks...

[Chris McDonough]

On 05/21/2012 04:59 PM, Tarek Ziadé wrote:
> 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.

It sounds like a reasonable task for me to try out.  In the meantime 
we've had a bit of a family emergency which will take some time to 
overcome and I won't be able to dedicate much energy to this.  As a 
result, I have to declare bankruptcy here, so I'll have to live with 
whatever I get.

I'm hoping though that someone else will step up here and do an 
evaluation and try to get things like Pyramid and popular Zope packages 
installed in a way that makes sense for straddling Python 2 and Python 
3.  I suspect if no one does this, it's going to be rough going.

- C