Joerg Sonnenberger <joerg%britannica.bec.de@localhost> writes:
Thanks - I'm starting to understand this now.
> On Fri, Jul 23, 2010 at 02:07:24PM -0400, Greg Troxel wrote:
>> After including lang/python/egg.mk, 'make package' (DESTDIR mode) fails
>> with:
>>
>> usage: setup.py [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>> or: setup.py --help [cmd1 cmd2 ...]
>> or: setup.py --help-commands
>> or: setup.py cmd --help
>>
>> error: option --single-version-externally-managed not recognized
>
> This is a sign that it isn't using setuptools,
True, it seems to be 'distutils'.
> which is a requirement
> for working with older Python versions at the very least.
I don't follow that. Do you mean pre-2.4?
>> 1) Why does PY_NO_EGG default to yes? Should it be set to NO in egg.mk?
>> Or is that about not installing egg metadata in the package directory
>> itself?
>
> Packages using egg should also use setuptools. That would take care of
> the rest.
I don't follow 'using egg'. This package installs a perfectly ok
seeming egg file, unless we've gone to the trouble of disabling it.
>> 2) Is a python module that has setup.py and doesn't implement
>> --single-version-externally-managed broken?
>
> Tentatively yes.
I've started to think that it's old-fashioned (pre-setuptools) more than
broken.
>> A) that --single-version-externally-managed is the python way for an
>> egg-aware package to be told
>>
>> 1) there will only be one version of this package installed, and
>>
>> 2) the egg data should be in .../site-package so that it will be found
>> by require
>
> Yes, it stops the package from using a full subdirectory, making it more
> similar to the classic way. Meta data is still in the
> ${EGGNAME}-${PYVERS}.egg-info subdirectory.
So I think py-crypto is simply 'classic way only'.
>> B) py-crypto is not really 'egg aware' in the modern mainstream sense,
>> but in some more limited sense that still allows require to find it.
>
> I can't talk about py-crypto, but if it doesn't use setuptools, it
> shouldn't require egg meta data at all.
The problem I'm having isn't that py-crypto requires egg metadata, it's
that things that depend on it use the requirements system to see if it
is installed. The native build as invoked by extension.mk, absent our
PY_NO_EGG, installs an egg file, and it seems to be what require wants.
So I think there's a kind of 'oldstyle egg' python package that produces
an egg file but doesn't use the full-blown setuptools to make
all-inclusive egg directories, and the oldstyle eggs are very close to
what we've decided pkgsrc wants.
What problem is PY_NO_EGG trying to solve? (It seems necessary to set
PY_NO_EGG=no for old-style egg packages like py-crypto in order to get a
working egg file installed.) (I didn't understand this from the
lang/python/*.mk sources, patch-av, or from the guide.)
The lang/python/*.mk files are in need of more comments. Unless someone
more clueful about python would like to do it, I'll put in a few notes
resulting from this discussion.
Attachment:
pgpf5NazfL6Q0.pgp
Description: PGP signature