Re: [Distutils] formencode as .egg in Debian ??
Hi,
Phillip J. Eby:
> I'm thinking that perhaps I should add an option like
> '--single-version-externally-managed' to the install command so that you
> can indicate that you are installing for the sake of an external package
> manager that will manage conflicts and uninstallation needs. This would
> then allow installation using the .egg-info form and no .pth files.
>
You might shorten that option a bit. ;-) I agree that this would be a
good option to have.
> >People will often inspect sys.path to understand where Python
> >is looking for their code.
>
> As I pointed out, eggs give you much better information on this.
The .egg metadata does. That, as you say, is distinct from the idea of
packaging the .egg as a zip file. Most likely, one that includes .pyc
files which were byte-compiled with different file paths; That causes no
problems whatsoever ... until you get obscure ideas like trying to step
through the code with pdb, or opening it in your editor to insert an
assertion or a printf, trying to figure out why your code breaks. :-/
> >Debian policy currently seems to require that the dependencies are
> >provided as plain text in a patch to the upstream sources(*). So the
> >idea certainly is that dependencies are managed by the developer,
> >not automatically.
>
> I'm only interested in what's helpful or useful to Debian developers and
> users, not what the current policy is. Policies tend to adapt to fit
> things that are useful, or else they become more of a drawback than a
> benefit. I mention these things because they may allow the process and
> policy to be improved, to everyone's benefit.
That's not exactly negotiable. Debian has a packaging format which
resolves generic installation dependencies on its own. Therefore it
cannot depend on Python-specific .egg metadata. Therefore we need a way
to translate .egg metadata to Debian metadata.
> I remain concerned about how such packages will work with namespace
> packages, since namespace packages mean that two different distributions
> may be supplying the same __init__.py files, and some package managers may
> not be able to deal with two system packages (e.g. Debian packages, RPMs,
> etc.) supplying the same file, even if it has identical contents in each
> system package.
>
Debian packaging has a method to explicitly rename a different package's
file if it conflicts with yours ("dpkg-divert"; it does _not_ depend on
which package gets installed first). IMHO that's actually superior
randomly executing only one of these files, since you are aware that
there is a conflict (the second package simply doesn't install if you
don't fix it), and thus can handle it intelligently.
--
Matthias Urlichs | {M:U} IT Design @ m-u-it.de | smurf@smurf.noris.de
Disclaimer: The quote was selected randomly. Really. | http://smurf.noris.de
- -
A father doesn't destroy his children.
-- Lt. Carolyn Palamas, "Who Mourns for Adonais?",
stardate 3468.1.
Reply to: