[Distutils] Setuptools' goal in rpm/deb-based systems

[Jeff Pitman]

On 12/29/05, Kevin Dangoor <dangoor at gmail.com> wrote:
> On 12/29/05, Jeff Pitman <jeff.pitman at gmail.com> wrote:
> > (Because turbogears script generation is not trivial
> > to package. I think I'll just include a generated script as one of the
> > Sources, for now.)
>
> Note that TurboGears 0.9 absolutely needs to run as a proper egg.
> (When you say you're including the generated script as part of the
> sources, I'm not sure if that means that you're bypassing the egg
> packaging entirely...)

It's just /usr/bin/tg-admin.

> > Also, are there efforts to detect if a package is already installed?
> > For example, if "python-sqlobject" is installed, can setuptools detect
> > the lib if the install_requires has "SQLObject"? I think peering
> > between .egg and .deb/.rpm to be a difficult problem. So, having it
> > all or nothing would be a cleaner policy. .deb/.rpm to manage /usr
> > installed packages/modules and .egg to manage $HOME installed
> > packages.
>
> The problem is with the missing metadata. setuptools doesn't know what
> version of SQLObject that is, and TurboGears most definitely requires
> 0.7 and up. I think the goal is ultimately to have system-installed
> .debs/.rpms that are also eggs (with the proper metadata).

Do you mean package the egg-info in with the rpm/deb? BTW, TurboGears
needs to be installed as rpm to ever be included in Fedora Extras (and
as .deb in Debian/Ubuntu land). This is a matter of policy. And people
are very wary about pollution of system directories like /usr.
Technically, files updated during runtime should go in /var (like
logs, state, and crap).

> TurboGears
> 0.9 makes use of setuptools' extension mechanism which is why the egg
> metadata needs to be available.

During runtime or during installation?

--
-jeff