[Distutils] [Bulk] Re: .egg in Debian summary?

[Vincenzo Di Massa]

Alle 18:56, mercoledì 23 novembre 2005, Phillip J. Eby ha scritto:
> At 04:39 PM 11/23/2005 +0100, Vincenzo Di Massa wrote:
> >I think setuptools could really help Debian developer as well as Fedora,
> >Mandriva, Gentoo... by:
> >1) providing functionality to install files outside of egg dir/zip (for
> >example one could install code to site-packages and data-files to
> > /usr/share/ or somewhere else)
>
> There will be some steps towards this in the 0.7 series, although initially
> that's going to be by providing user-executed post-installation tools,
> which would also be executable by packager-defined postinstallation
> steps.  Since easy_install is not a package manager, however, I would
> prefer users be able to trust that running easy_install is only going to
> make a Python package and some scripts available, and not do anything to
> files elsewhere on their system.  This position may evolve over time, since
> there are a lot of other features that (in my mind at least) need to come
> first before I can think deeply about the issue.  (Related issues: header
> file installation, documentation, etc.)

That really sounds GREAT! 
What about providing an .egg-data file to be installed with the egg in 
site-packages or uncompressed and installed by an external packaging 
mechanism? Metadata in .egg packages could allow egg using projects to find 
the corresponding .egg-data package anywhere even if it unzipped and its 
contents spread all over the filesistem.
I think this will be useful and nice. :-)

> >2) providing a "fakeroot" option to fool setup.py (for example I want
> >setuptools to install the files in
> > debian/tmp/usr/lib/pythonX.Y/site-packages and scripts in
> > debian/tmp/usr/bin and everithing must work when it copied to
> > /usr/{bin,lib}.
>
> There is in fact such an option now; as far as I know the --root option to
> "setup.py install" should do it, and I am pretty sure it's used by
> bdist_rpm.

You are right. And I did know about it :-) . 
I just asked for the feature in the wrong place: the --root would be usefull 
in easy_install too, not just in setup.py. This would allow you to prepare 
eggs distributions out of packages that are not using setuptools and put the 
stuff into a --root dir (which is what you are proposing Debian developers to 
do with the upcoming new setuptools version able to install "legacy-eggs").

> >2) providing a paseable output with setup process data like: dependencies
> >(meet and unmett), files installed, author, license, and so on
>
> Perhaps you could provide a sample of what you have in mind?  A patch would
> be even better, although I would be using it mainly to understand what
> you'd like to have and not necessarily as a basis for implementing it.

I think that what I have in mind is to find out what is best to provide. There 
are many packaging systems out there and each one has its metadata format.
My proposal is to find out what setuptools can do to generate a nice metadata 
file that describes the egg (version, author, wesite, gpg signature, .... 
anything that is usefull and doable), its dependencies (name, version, ???) 
and ???.
That metadata file could be created when the egg file is created (using an 
option like --record).
Parsing that file a python egg can be semi-automatically put into any pakage 
format (deb, rpm, tgz, ???) simply building a little app that converts 
setuptools metatada format to target platform metadata.

> >All this will let people just "convert" the output of setuptools into an
> > rpm specfile, debian dir, gentoo ebuild and so on.
> >All that is needed is just a common metadata format that can be parsed by
> >tools like easy-deb, easy-rmp easy-ebuild easy-(???).
>
> Note that easy_install and install have --record options that write the
> names of all installed files or directories to a file for you.  The
> remaining metadata you're asking about can already be queried via the
> pkg_resources API, since it's part of the resulting
> eggs.  'someEgg.get_metadata("PKG-INFO")' will get you the PKG-INFO file
> with all the standard distutils metadata, for example.  The 'requires()'
> method gives information about dependencies.

It would be nice to arrange a set of metadata to be put toghether in just one 
file built when the egg is biult. 
Maybe you could add requires() output in PKG-INFO (making it comply with 
version 1.2 which is in PEP). So the output file cou then just be the 1.2 
PKG-INFO.

> >This way setuptools provides the information to distribution maintainers
> > in a well documented, api independent way.
>
> Well, if you want API independence, you can directly look at the .egg-info
> or EGG-INFO directory contents, as the data is in plain-text files like
> requires.txt and PKG-INFO.  PKG-INFO is a PEP-defined format, and the
> requires.txt format has been stable for maybe 7 months now.  I don't
> anticipate any changes to it.
>
> >  Distribution maintainers can use this
> >info to reorganize, repackage, invent new package formats, but without
> >involving setuptools and python developers.
>
> Fair enough, although you should keep in mind that there are only three
> valid installation layouts for egg-specific projects: .egg zipfile, .egg
> directory, and "old school" installation with an .egg-info directory
> installed alongside.  Anything else, and it would involve changing the egg
> runtime to work with it.

I know, and I think eggs are GOOD even because they are(or will be with newer 
versions of setuptools) easy to put into other packages types (like debs).
But you know what packagers(meaning peoplewho does packaging) are like: they 
have policies and tend to reinvent the weel (and hot water too!!!) every time 
just becouse they have policies.
It is sad to listen to good developers spreading FUDware thoughts about nice 
FLOSS projects like yours.
I think that the best thing would be to give them a plaintext file to parse 
and the egg as is. They will find a very mind and time consuming way to 
those. But that is not your business anymore: people at DistroX don't like 
eggs? They can rewrite the egg in assembly if they like to... that will not 
hurt your project I think.  If eggs are GOOD (as we think) other distros may 
have more success among python developers and users.

Vincenzo

> >About the pythonpath and pth files handlind:
> >if a project A really wants to use project B eggs it can easily require
> > them without the need for a pth file.
> >If project C wants to use project B, but project C is not setuptools aware
> >one
> >could patch project C (just adding require() to it) instead of paching
> >project B and project A removing egg support from them.
>
> Note that if C is an application rather than a library, one can add the
> requirements to setup.py and use easy_install to install it, which will
> create script wrappers that perform the necessary require()
> operations.  So, you don't have to patch C very deeply in this case.  In
> addition, the scripts will require() C itself, so you don't need to install
> C with a .pth unless it is a library that is needed by something else that
> is not packaged using this system.
>
> Basically, the whole thing is designed so that as long as a project is
> setuptools-based, it doesn't need explicit require() calls, as these are
> handled by setuptools.  Only if you want a project to be *always* on
> sys.path do you need a .pth file.

I know, and if I were a Debian developer I would change the (holy) Debian 
Python Policy to let a module be instaleed without pth if that is ok!
:-)

> >Onother possible solution would be to have:
> >python-A
> >python-pypi-A
> >python-B
> >python-pypi-B
> >python-C
> >
> >Where
> >python-B) depends on python-pypi-A and just provides the pth file (handled
> >like easy-deb does)
> >python-pypi-B) contains the egg
> >
> >So project C will depend on python-B, which will install the pth. But if
> >project B is required just by project A which is setuptools aware the
> >dependency will be on python-pypi-B: the pth file will not be installed.
>
> So, you're saying that python-foo would install 'foo' such that it is
> always on sys.path, but python-pypi-foo simply installs 'foo' in such a way
> that is discoverable by the egg runtime.  That's an interesting idea, I'll
> have to think a while about the consequences of that before I comment on it
> further.

Vincenzo

	

	
		
___________________________________ 
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB 
http://mail.yahoo.it