Setuptools' goal in rpm/deb-based systems
Hi, This may have been discussed ad nauseum already, but as I tried to package turbogears for Fedora/CentOS, I thought I'd throw in 2 cents. From a .deb and .rpm perspective, it is highly discouraged to install non-system managed files into non-$HOME areas (esp. /usr). Even for many, /usr/local is highly frowned upon (eg. ./configure; make; make install mantra). I see that --single-version-externally-managed has been added as an option so that .deb/.rpm packaging can take advantage of that relying upon apt/yum/smart to take care of business. Hopefully, this will be pushed out soon. (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.) I think the goal for setuptools on rpm/deb-based systems should focus on getting $HOME setup and managed correctly for packages not provided by the system. For example, if I had an ISP which provided python2.4, but not TurboGears, then I could use .egg to manage a setup in $HOME to use the packages correctly. Currently, -d/-s and other options can be used. But, if the user isn't root, maybe it should be the default behavior: install and manage in $HOME. 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. Thoughts? -- -jeff
On 12/29/05, Jeff Pitman <jeff.pitman@gmail.com> wrote:
This may have been discussed ad nauseum already, but as I tried to package turbogears for Fedora/CentOS, I thought I'd throw in 2 cents.
Hey, great! I'm sure many will appreciate the effort!
I see that --single-version-externally-managed has been added as an option so that .deb/.rpm packaging can take advantage of that relying upon apt/yum/smart to take care of business. Hopefully, this will be pushed out soon. (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...)
I think the goal for setuptools on rpm/deb-based systems should focus on getting $HOME setup and managed correctly for packages not provided by the system. For example, if I had an ISP which provided python2.4, but not TurboGears, then I could use .egg to manage a setup in $HOME to use the packages correctly. Currently, -d/-s and other options can be used. But, if the user isn't root, maybe it should be the default behavior: install and manage in $HOME.
Setting things up in $HOME is definitely a good thing, and doesn't take very much effort. I hope more ISPs will do so (and it's something I'm working on with TurboGears hosting providers).
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). TurboGears 0.9 makes use of setuptools' extension mechanism which is why the egg metadata needs to be available. Kevin
On 12/29/05, Kevin Dangoor <dangoor@gmail.com> wrote:
On 12/29/05, Jeff Pitman <jeff.pitman@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
On 12/29/05, Jeff Pitman <jeff.pitman@gmail.com> wrote:
On 12/29/05, Kevin Dangoor <dangoor@gmail.com> wrote:
On 12/29/05, Jeff Pitman <jeff.pitman@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.
Oh, OK. If that's all you did, that shouldn't pose a problem.
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?
I believe that's what Phillip's recent changes have been about. They provide a way to put the egg metadata inside the package directory so that it can install like a traditional package but still have the appropriate metadata. I'll stop commenting at this point, though, because Phillip's the authoritative source and I've never had to personally walk down the path of packaging an egg up into something else.
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).
Absolutely.
TurboGears 0.9 makes use of setuptools' extension mechanism which is why the egg metadata needs to be available.
During runtime or during installation?
During runtime. Certain parts of TurboGears can be extended just by installing an egg with the additional functionality. TurboGears itself uses this mechanism to define the base pieces. (tg-admin commands are an example of this: anyone can create an egg that adds tg-admin commands. the existing commands are all defined in the same way that a user would create commands.) Kevin
On 12/29/05, Kevin Dangoor <dangoor@gmail.com> wrote:
On 12/29/05, Jeff Pitman <jeff.pitman@gmail.com> wrote:
On 12/29/05, Kevin Dangoor <dangoor@gmail.com> wrote:
TurboGears 0.9 makes use of setuptools' extension mechanism which is why the egg metadata needs to be available.
During runtime or during installation?
During runtime. Certain parts of TurboGears can be extended just by installing an egg with the additional functionality. TurboGears itself uses this mechanism to define the base pieces. (tg-admin commands are an example of this: anyone can create an egg that adds tg-admin commands. the existing commands are all defined in the same way that a user would create commands.)
So, they're plugins that extend tg-admin commands. In the .rpm/.deb space what would happen here is that these plugins would also be installed as .rpm/.deb. This is kind of like Twisted 2.0+ after the split. What would be good here is to have .eggs install into $HOME and tg-admin still pickup on them. -- -jeff
On 12/29/05, Jeff Pitman <jeff.pitman@gmail.com> wrote:
So, they're plugins that extend tg-admin commands. In the .rpm/.deb space what would happen here is that these plugins would also be installed as .rpm/.deb. This is kind of like Twisted 2.0+ after the split. What would be good here is to have .eggs install into $HOME and tg-admin still pickup on them.
If the system is set up correctly, the users could install the plugins as .rpms/.debs *or* install the eggs to their $HOME. Either way should work. Kevin -- Kevin Dangoor Author of the Zesty News RSS newsreader email: kid@blazingthings.com company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.com
participants (2)
-
Jeff Pitman -
Kevin Dangoor