tech-pkg archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: python egg info

Joerg Sonnenberger <> 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/, 'make package' (DESTDIR mode) fails
>> with:
>>   usage: [global_opts] cmd1 [cmd1_opts] [cmd2 [cmd2_opts] ...]
>>      or: --help [cmd1 cmd2 ...]
>>      or: --help-commands
>>      or: 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
>> 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 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

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

Home | Main Index | Thread Index | Old Index