-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs
This is the third round of the Python Egg Draft. It contains changes proposed at today's packaging meeting.
# Sep 11, 2007 -- Add note that all eggs must be rebuilt from source. * Add summary of egg on-disk formats. * Revise where this information will be placed in the Guidelines. o Make most of it its own page o Add a short checklist of Must/Shoulds to go on Packaging/Python.
And from slightly before the meeting:
* Make the switch for eggs within distutils be F9 instead of F8 after talking with Jeremy. o Add some mailing list discussions to the links section. o Add a sample README.fedora file.
I think I got everything except virtual Provides and virtual Requires. I'd like to make that a separate change to be discussed after we make sure we'll switch distutils egg generation on for F9. My reasoning is this:
* Currently python doesn't have virtual provide symbols like perl or php do. * If we turn on egg generation in distutils, practically every python module is going to have egg-info.
So if we start now with two separate namespaces python-egg(MODULE) and python(MODULE), by F-9 we could have everything using python-egg(MODULE) and next to nothing using python().
There are some little wrinkles in this and it may also be affected by Panu's work on a python-dependency-extractor for rpm. I'll send out a message on this shortly.
- -Toshio
On Tue, 11 Sep 2007, Toshio Kuratomi wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
http://fedoraproject.org/wiki/PackagingDrafts/PythonEggs
This is the third round of the Python Egg Draft. It contains changes proposed at today's packaging meeting.
# Sep 11, 2007 -- Add note that all eggs must be rebuilt from source.
- Add summary of egg on-disk formats.
- Revise where this information will be placed in the Guidelines.
o Make most of it its own page o Add a short checklist of Must/Shoulds to go on Packaging/Python.
And from slightly before the meeting:
- Make the switch for eggs within distutils be F9 instead of F8 after
talking with Jeremy. o Add some mailing list discussions to the links section. o Add a sample README.fedora file.
I think I got everything except virtual Provides and virtual Requires. I'd like to make that a separate change to be discussed after we make sure we'll switch distutils egg generation on for F9. My reasoning is this:
- Currently python doesn't have virtual provide symbols like perl or php do.
- If we turn on egg generation in distutils, practically every python
module is going to have egg-info.
So if we start now with two separate namespaces python-egg(MODULE) and python(MODULE), by F-9 we could have everything using python-egg(MODULE) and next to nothing using python().
There are some little wrinkles in this and it may also be affected by Panu's work on a python-dependency-extractor for rpm. I'll send out a message on this shortly.
Separating the namespaces is a fundamental problem for the dependency extractor. For provides this is obviously not an issue, but requires need to be generated without being able to actually locate (and possibly import) the actual module. Python syntax for importing egg- and regular modules is the same, so they need to live in the same namespace, otherwise the manual Requires just turn into manual BuildRequires and the depency extractor will be just adding syntactic sugar for nothing :)
- Panu -
Panu Matilainen wrote:
Separating the namespaces is a fundamental problem for the dependency extractor. For provides this is obviously not an issue, but requires need to be generated without being able to actually locate (and possibly import) the actual module. Python syntax for importing egg- and regular modules is the same, so they need to live in the same namespace, otherwise the manual Requires just turn into manual BuildRequires and the depency extractor will be just adding syntactic sugar for nothing :)
I think I've figured out a way to make this almost work:: import sqlalchemy
is equal to Requires python(sqlalchemy)
Any of these:: __requires__='SQLAlchemy' pkg_resources.require('SQLAlchemy') requires.txt: install_requires = [ 'SQLAlchemy' ]
are equal to python-egg(sqlalchemy)
This breaks down when thinking about what happens in this case:: __requires__='TurboGears' import pkg_requires import sqlachemy
At this point you have to know whether TurboGears or anything that it requires has a requires.txt which includes ['SQLAlchemy']. If it does we are using the egg interface to sqlalchemy. If it doesn't we are using the normal interface.
So, assuming we remove our patch that stops generation of egg-info files for distutils generated modules for F9, I agree that there isn't very much value for quite a bit of work.
-Toshio
On Wed, 12 Sep 2007, Toshio Kuratomi wrote:
Panu Matilainen wrote:
Separating the namespaces is a fundamental problem for the dependency extractor. For provides this is obviously not an issue, but requires need to be generated without being able to actually locate (and possibly import) the actual module. Python syntax for importing egg- and regular modules is the same, so they need to live in the same namespace, otherwise the manual Requires just turn into manual BuildRequires and the depency extractor will be just adding syntactic sugar for nothing :)
I think I've figured out a way to make this almost work:: import sqlalchemy
is equal to Requires python(sqlalchemy)
Any of these:: __requires__='SQLAlchemy' pkg_resources.require('SQLAlchemy') requires.txt: install_requires = [ 'SQLAlchemy' ]
are equal to python-egg(sqlalchemy)
This breaks down when thinking about what happens in this case:: __requires__='TurboGears' import pkg_requires import sqlachemy
At this point you have to know whether TurboGears or anything that it requires has a requires.txt which includes ['SQLAlchemy']. If it does we are using the egg interface to sqlalchemy. If it doesn't we are using the normal interface.
So, assuming we remove our patch that stops generation of egg-info files for distutils generated modules for F9, I agree that there isn't very much value for quite a bit of work.
Let me put it this way: why exactly do you want the eggs in a separate namespace? If using modules from them *required* using new interfaces it'd be a different story, but since they can be imported just like any regular module they should be in the same namespace. (or am I missing something here - I'm certainly not very familiar with the egg stuff?)
One possibility would be to *only* extract python module dependencies from egg modules and software using the new requires interfaces and simply forget about the old-style modules.
- Panu -
Panu Matilainen wrote:
On Wed, 12 Sep 2007, Toshio Kuratomi wrote:
Panu Matilainen wrote:
Separating the namespaces is a fundamental problem for the dependency extractor. For provides this is obviously not an issue, but requires need to be generated without being able to actually locate (and possibly import) the actual module. Python syntax for importing egg- and regular modules is the same, so they need to live in the same namespace, otherwise the manual Requires just turn into manual BuildRequires and the depency extractor will be just adding syntactic sugar for nothing :)
I think I've figured out a way to make this almost work:: import sqlalchemy
is equal to Requires python(sqlalchemy)
Any of these:: __requires__='SQLAlchemy' pkg_resources.require('SQLAlchemy') requires.txt: install_requires = [ 'SQLAlchemy' ]
are equal to python-egg(sqlalchemy)
This breaks down when thinking about what happens in this case:: __requires__='TurboGears' import pkg_requires import sqlachemy
At this point you have to know whether TurboGears or anything that it requires has a requires.txt which includes ['SQLAlchemy']. If it does we are using the egg interface to sqlalchemy. If it doesn't we are using the normal interface.
So, assuming we remove our patch that stops generation of egg-info files for distutils generated modules for F9, I agree that there isn't very much value for quite a bit of work.
Let me put it this way: why exactly do you want the eggs in a separate namespace? If using modules from them *required* using new interfaces it'd be a different story, but since they can be imported just like any regular module they should be in the same namespace. (or am I missing something here - I'm certainly not very familiar with the egg stuff?)
Well, the way I'm proposing in the egg draft we will have compat-packages that are only importable via an egg interface. For instance python-sqlalchemy0.3 has these directories:: %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/ %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/sqlalchemy
To be able to import it you need to do something like this:
__requires__='SQLAlchemy >= 0.3, < 0.4alpha' import pkg_resources import sqlalchemy
Or manually add %{python_sitelib}/SQLAlchemy-0.3.10-py2.5.egg/sqlalchemy to sys.path.
The main python-sqlalchemy module would be directly importable or you could select it specifically using something like __requires__='SQLAlchemy >= 0.4, < 0.5'.
One possibility would be to *only* extract python module dependencies from egg modules and software using the new requires interfaces and simply forget about the old-style modules.
I'd rather we extract old-style modules and forget about eggs as the eggs don't come into play as often for us.
-Toshio
packaging@lists.fedoraproject.org