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

Re: [Distutils] formencode as .egg in Debian ??



At 11:54 AM 11/25/2005 +0100, Vincenzo Di Massa wrote:
Alle 11:04, venerdì 25 novembre 2005, David Arnold ha scritto:
> But, if compatible versions of those dependencies are already installed
> as Debian packages *without* egg metadata, will these be ignored?

Yes, they will.

> Even if it was possible for Debian to extend this downloading mechanism
> so that it looked for dependencies via apt-get before trying to install
> from the raw source or egg or whatever, it would usually be the case
> that the user running the newly downloaded Python application would not
> have permission to install system packages.

I think easy_install coud be patched by debian packagers (or made configurable by Phillip) to add a further check on dependency checking: it could check if a
dependency is already provided by system packages.

This could be done with entry points that are then satisfied by a Debian-speciifc plugin. But, I don't think this should be used to apt-get things, just to check for availability. If you want to fetch stuff as Debian system packages you should use easy_deb in the case where a Debian package isn't already available.

However, the problem in creating such a dependency checking plugin is that it *still* needs to map PyPI name+version -> Debian name+version, which is a harder problem, I think, than simply adding the .egg-info files to the Debian dependencies.


Philliph, do you like this idea? It is just adding a hook to dependency
checking where distributors can call ther depency checking tools. That way
the Name+Vesion problem is resolved without putting empty files anywhere.

Yeah, except that as you pointed out, you still have to have the mapping exist somewhere as metadata for that hook to read. Which in the simplest case would consist of some sort of flag files installed with the packages... like an .egg-info file. So, it seems like it would be just as easy to do that, and not have to:

1. maintain the hook in setuptools, which in this case is somewhat tricky to bootstrap because the dependency resolver needs to be working before the hook is activated, but the hook would be part of the dependency resolver. So, it's a bit more fragile than the common sort of hook provided by setuptools.

2. have the Debian folks maintaining both a module to hook into this, and a database of package mappings.

It seems to me like the simpler solution is just to have the packages install the .egg-info, and nobody has to maintain a mapping database because the setup.py's the .debs are built from already have the info needed, and there's no special code having to be jointly maintained to make the detection work.



Reply to: