Hi, I'm planning to make a port for Distribute to make it more accessible to users. However, thinking about up coming 0.7 release, which will break the compatibility with setuptools, I started wondering it's not so easy to make a package for distribute. If I understand correctly, Distutils 0.7 is like Python 3.x in some ways. It breaks compatibility and 0.7 and 0.6 both will continue to be developed in parallel at least a year or so. That sounds great but we can't have two versions of a Python module at the same time. Take a Jinja and Jinja2 for example. It has to have different names to make both package available at the same systen at the same time. For Distribute, there would be a few options to work around this: 1) Make 0.6 and 0.7 different package, like Distribute and Distribute2 (Jinja like solution) 2) Make 0.7 fat package, which includes 0.6(setuptools compat) features as deprecated. *) YOUR IDEAS COME HERE. Is there anyone having any other solutions? And what actually Distribute developers are thinking about this problem? # I heard Gentoo provides Distribute as setuptools but I think it's rather rude Thanks in advance.
On Sun, Oct 4, 2009 at 5:10 PM, Akira Kitada <akitada@macports.org> wrote:
I'm planning to make a port for Distribute to make it more accessible to users.
That's very much appreciated :)
For Distribute, there would be a few options to work around this:
1) Make 0.6 and 0.7 different package, like Distribute and Distribute2 (Jinja like solution) 2) Make 0.7 fat package, which includes 0.6(setuptools compat) features as deprecated. *) YOUR IDEAS COME HERE.
I would just release the current 0.6 code as a port called distribute for now. We don't know yet when the 0.7 version is actually going to arrive. How exactly it looks like might very well change during the next months. So let's figure out how to deal with 0.7 once it is actually anywhere near. In general I would assume each package management system to either have support for multi-version support or have a standard way to deal with new feature releases. It's pretty common for any code to give up backwards compatibility to some degree over time. Distribute is no different here. Hanno
On Sun, Oct 4, 2009 at 5:28 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
For Distribute, there would be a few options to work around this:
1) Make 0.6 and 0.7 different package, like Distribute and Distribute2 (Jinja like solution) 2) Make 0.7 fat package, which includes 0.6(setuptools compat) features as deprecated. *) YOUR IDEAS COME HERE.
I would just release the current 0.6 code as a port called distribute for now.
We don't know yet when the 0.7 version is actually going to arrive. How exactly it looks like might very well change during the next months. So let's figure out how to deal with 0.7 once it is actually anywhere near.
In general I would assume each package management system to either have support for multi-version support or have a standard way to deal with new feature releases. It's pretty common for any code to give up backwards compatibility to some degree over time. Distribute is no different here.
Well in any case, what is sure is that we need to maintain a working 0.6 distribution to allow projects like pip or virtualenv to switch to Distribute if they want. For 0.7, what is also required is to be able to install it together with 0.6 because the 0.7 version will provide new features/changes that a project might want to use while working with 0.6, and other projects requiring 0.6 would be broken in case 0.7 removes 0.6. For the long term I find the fat package solution we've discussed earlier on IRC nicer because it will probably allow us to fix some bugs in the 0.6 part by using some bits of 0.7 underneath. Now for shipping Distribute 0.6 in MacPorts, I don't know how the dependency system works there, but the best way would be to remove the setuptools distribution as a pre-request of Distribute installation (and vice-versa), The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now, and that's what we might do in Debian and Ubuntu (that's just a thaught at this time in there). In any case, the chosen solution will be far from perfect. Cheers Tarek -- Tarek Ziadé | http://ziade.org | オープンソースはすごい! | 开源传万世，因有你参与
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'? DEPEND="!!<dev-python/setuptools-0.6.3-r2" Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository? -srid
Sridhar Ratnakumar a écrit :
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'?
DEPEND="!!<dev-python/setuptools-0.6.3-r2"
Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools
The src_uri explicitly target to DISTRIBUTE. grep SRC /usr/portage/dev-python/setuptools/setuptools-0.6.1.ebuild SRC_URI="http://pypi.python.org/packages/source/d/distribute/distribute-${PV}.tar.gz" If they want to reswitch to bare metal setuptools, they will update this url.
release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository?
-srid
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
-- -- Cordialement, KiOrKY GPG Key FingerPrint: 0x1A1194B7681112AF
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now Interesting. Gentoo uses distribute but retains the name 'setuptools'?
DEPEND="!!<dev-python/setuptools-0.6.3-r2"
Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository? Debian would probably treat one side or the other as a branch. Sounds
Sridhar Ratnakumar wrote: like gentoo has decided that distribute is the main line, which would define a new release of setuptools as a branch. So it would probably be something like setuptools-0.6.3pje-r0 or the like. That way it's progress from 0.6.3, but would be overwritten by a 0.6.4. (Or, they'd just ignore the pje release). --rich
2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'?
It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute.
Ah. But what if PJE releases setuptools with the *same* version number 0.6.3? What would the gentoo folks do in order to get the new setuptools release in their packaging system? Or did they make a decision of totally dropping setuptools from their repository?
We could switch to back to Setuptools only if Setuptools became more maintained than Distribute. -- Arfrever Frehtes Taifersar Arahesis
On Thu, Oct 08, 2009 at 11:07:13PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'?
It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute.
I started thinking about what it might take to do this for Fedora as well. There's a number of worries I have but it sounds attractive because of the increased maintainence support from distribute's upstream. An alternative I thought of would be for us to ship both distribute-0.6 and distribute-0.7 (when it arrives) and parallel install them. Then we can patch the setuptools using packages we maintain to check first for the 0.6 distribute and fall back on setuptools if it's not found. That would hopefully get a bunch of upstreams onto a better supported code base. My question is: will Distribute have a parallel installation plan? For instance, renaming the module provided by 0.7 distribute2? If so, this makes a lot of sense. If not, it's the ability of gentoo to reuse the setuptools name that makes parallel installation of distribute-0.6 and distribute-0.7 easier. -Toshio
On Fri, Oct 9, 2009 at 12:03 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
On Thu, Oct 08, 2009 at 11:07:13PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'?
It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute.
I started thinking about what it might take to do this for Fedora as well. There's a number of worries I have but it sounds attractive because of the increased maintainence support from distribute's upstream.
An alternative I thought of would be for us to ship both distribute-0.6 and distribute-0.7 (when it arrives) and parallel install them. Then we can patch the setuptools using packages we maintain to check first for the 0.6 distribute and fall back on setuptools if it's not found. That would hopefully get a bunch of upstreams onto a better supported code base.
My question is: will Distribute have a parallel installation plan? For instance, renaming the module provided by 0.7 distribute2? If so, this makes a lot of sense. If not, it's the ability of gentoo to reuse the setuptools name that makes parallel installation of distribute-0.6 and distribute-0.7 easier.
We are not sure yet, but when 0.7 will be ready we have two choices: 1- we ship 0.7 under a new name - e.g. like "distribute2" 2- we ship a fat 0.7 with the old 0.6 packages and modules included. I think 1- is better, because it's cleaner in many ways. Plus, people that will start to use 0.7 will not mind using the "distribute2" name. Tarek
On Fri, Oct 9, 2009 at 12:27 AM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
We are not sure yet, but when 0.7 will be ready we have two choices:
1- we ship 0.7 under a new name - e.g. like "distribute2" 2- we ship a fat 0.7 with the old 0.6 packages and modules included.
I think 1- is better, because it's cleaner in many ways. Plus, people that will start to use 0.7 will not mind using the "distribute2" name.
notice that I was in favor of 2- earlier but I changed my mind after some readings today ;)
Tarek Ziadé wrote:
1- we ship 0.7 under a new name - e.g. like "distribute2"
You could even take the opportunity to rename it completely to something that makes sense ;-) To re-iterate my argument: Distribute doesn't distribute anything. If anything was to be called Distribute, it'd be the PyPI software. Calling it Installer or Pacman might make more sense... Chris
On Fri, Oct 9, 2009 at 1:17 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Tarek Ziadé wrote:
1- we ship 0.7 under a new name - e.g. like "distribute2"
You could even take the opportunity to rename it completely to something that makes sense ;-)
To re-iterate my argument: Distribute doesn't distribute anything. If anything was to be called Distribute, it'd be the PyPI software. Calling it Installer or Pacman might make more sense...
Sorry I won't run a new poll again, Distribute is the name. Besides, it's already on page #1 on google when I type 'python disribute' or 'distribute python' Tarek
Tarek Ziadé wrote:
Sorry I won't run a new poll again, Distribute is the name.
Besides, it's already on page #1 on google when I type 'python disribute' or 'distribute python'
*shrugs* I will state now that I will fight tooth and nail before anything called "distribute" gets into the stdlib that has nothing to do with distribution. That said, the sooner bits and pieces (version comparision, standard metadata, building of eggs, installation and removal of packages from a file system path) make it into the stdlib, the better. cheers, Chris -- Simplistix - Content Management, Batch Processing & Python Consulting - http://www.simplistix.co.uk
On Fri, Oct 9, 2009 at 4:34 PM, Chris Withers <chris@simplistix.co.uk> wrote:
Tarek Ziadé wrote:
Sorry I won't run a new poll again, Distribute is the name.
Besides, it's already on page #1 on google when I type 'python disribute' or 'distribute python'
*shrugs*
I will state now that I will fight tooth and nail before anything called "distribute" gets into the stdlib that has nothing to do with distribution.
Don't worry then. "distribute" will never get into the stdlib. What is likely to happen is that some bits it contains will make it in Distutils or pkgutil, etc. Tarek
On Fri, Oct 9, 2009 at 10:34 AM, Chris Withers <chris@simplistix.co.uk> wrote:
Tarek Ziadé wrote:
Sorry I won't run a new poll again, Distribute is the name.
Besides, it's already on page #1 on google when I type 'python disribute' or 'distribute python'
*shrugs*
I will state now that I will fight tooth and nail before anything called "distribute" gets into the stdlib that has nothing to do with distribution.
Not to slash turpentine on an already painted bikeshed, but since the project's aim is to be a module distribution manager for Python, I like the name "modisty" (*mod*ule *dist*ribution manager for P*y*thon). In cases where it refuses to install a package for some reason, it could claim that "modisty forbids" such an action [snicker]. :) By the way, regarding name changes, even big projects change names every now and then (Xorg and Wireshark spring to mind) and seem to get their Google ranking back pretty quickly. Google's very good about noticing when things change. ---John
2009/10/10 John Gabriele <jmg3000@gmail.com>:
Not to slash turpentine on an already painted bikeshed, but since the project's aim is to be a module distribution manager for Python, I like the name "modisty" (*mod*ule *dist*ribution manager for P*y*thon).
Ick. But "mopy-" is actually a good prefix. :) mopydist... Ah well, too late now, and Chris wouldn't like that either it's still "dist". -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Chris Withers kirjoitti:
Tarek Ziadé wrote:
1- we ship 0.7 under a new name - e.g. like "distribute2"
You could even take the opportunity to rename it completely to something that makes sense ;-)
While I agree that the name was badly chosen (for reasons you outline below), a name change at this point would introduce even more confusion.
To re-iterate my argument: Distribute doesn't distribute anything. If anything was to be called Distribute, it'd be the PyPI software. Calling it Installer or Pacman might make more sense...
Chris
_______________________________________________ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
2009-10-09 00:27:41 Tarek Ziadé napisał(a):
On Fri, Oct 9, 2009 at 12:03 AM, Toshio Kuratomi <a.badger@gmail.com> wrote:
On Thu, Oct 08, 2009 at 11:07:13PM +0200, Arfrever Frehtes Taifersar Arahesis wrote:
2009-10-04 23:52:25 Sridhar Ratnakumar napisał(a):
On Sun, 04 Oct 2009 13:41:06 -0700, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
The other way would be to use Distribute instead of Setuptools for what the packaging system is calling "setuptools". That's pretty much what is happening in Gentoo (arch) and UHU-Linux (dev), right now
Interesting. Gentoo uses distribute but retains the name 'setuptools'?
It's because Distribute 0.6.* installs setuptools.* modules. Distribute 0.7.* will be under name dev-python/distribute.
I started thinking about what it might take to do this for Fedora as well. There's a number of worries I have but it sounds attractive because of the increased maintainence support from distribute's upstream.
An alternative I thought of would be for us to ship both distribute-0.6 and distribute-0.7 (when it arrives) and parallel install them. Then we can patch the setuptools using packages we maintain to check first for the 0.6 distribute and fall back on setuptools if it's not found. That would hopefully get a bunch of upstreams onto a better supported code base.
My question is: will Distribute have a parallel installation plan? For instance, renaming the module provided by 0.7 distribute2? If so, this makes a lot of sense. If not, it's the ability of gentoo to reuse the setuptools name that makes parallel installation of distribute-0.6 and distribute-0.7 easier.
We are not sure yet, but when 0.7 will be ready we have two choices:
1- we ship 0.7 under a new name - e.g. like "distribute2" 2- we ship a fat 0.7 with the old 0.6 packages and modules included.
I suggest to ship 0.7 under name "distribute" and allow parallel installation of 0.6 and 0.7. E.g. Python 2.5 and 2.6 can be installed parallelly. -- Arfrever Frehtes Taifersar Arahesis
participants (12)
-
Akira Kitada -
Alex Grönholm -
Arfrever Frehtes Taifersar Arahesis -
Chris Withers -
Hanno Schlichting -
John Gabriele -
K. Richard Pixley -
kiorky -
Lennart Regebro -
Sridhar Ratnakumar -
Tarek Ziadé -
Toshio Kuratomi