Re: [Distutils] Packaging situation + mailing list rules
At 12:08 PM 7/2/2010 +0200, Tarek Ziadé wrote:
Hello,
From time to time this mailing list is getting very unpleasant to work in because some old disagreements, and because some people are starting to get really nasty.
Here's a reminder of the current packaging situation, and a few rules I suggest, for the benefit of all
1. Python <= 2.7 contains Distutils
2. Distutils is frozen, and won't evolve anymore
3. Setuptools is built on Distutils
4. Distribute forks Setuptools for various reasons. If you disagree with this choice, there's no need to send a mail here, because this is done. You can send me a private mail, but don't send a mail here because things are always getting nasty afterwards. Make sure to read the archives first, to understand why it was done.
5. Debian, Ubuntu and Fedora are using Distribute rather than Setuptools. If you find differences in the behavior, you can send a mail in this list, so we can fix Distribute. If you disagree with the distros choice, there's no need to send a mail here, because this is done. You can send *them* a mail, or tell them you disagree with this choice. Of course, the most effective behavior would be to work on having Distribute fixed if you find an issue, but that's up to you.
6. Distutils2 is being built, and has its own mailing list now. Distutils2 will replace Distutils in Python 3.2 or 3.3. It' s built on the various PEPs that were accepted lately, and any help is welcome.. The list is here: http://groups.google.fr/group/the-fellowship-of-the-packaging, and is moderated.
7. New members of the lists will not know the situation, so they won't be able to follow these rules of course. But people that are hanging around here for years can apply them.
Of course this is just a series of suggestion. You can disagree with all these rules if you want, but I think they need to be applied in this mailing-list for the benefit of all.
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools? I mean, if I realized that as the maintainer of a package that people were openly criticizing here, I could just post a list of rules to the SIG and prohibit it, I might've done that five years ago. ;-) (Nah, not really. But I'm certainly amused by how you've suddenly become concerned with "tone" in the SIG as soon as you get ONE person who's unhappy with distribute.) On a separate note, I'm curious why discussion of Distutils2 development is not in a formal Python SIG, such as the Distutils-SIG.
On Fri, Jul 2, 2010 at 11:00 PM, P.J. Eby <pje@telecommunity.com> wrote:
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools?
You noticed that too :) David
On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje@telecommunity.com> wrote: [..]
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools?
There's a huge gap between criticism + discussion, and the habitual flame of distribute vs setuptools. I think you know what I mean. Feel free to propose some changes on these rules, because I think you would be as happy as I would not to have to deal with flames like that.
I mean, if I realized that as the maintainer of a package that people were openly criticizing here, I could just post a list of rules to the SIG and prohibit it, I might've done that five years ago. ;-) (Nah, not really. But I'm certainly amused by how you've suddenly become concerned with "tone" in the SIG as soon as you get ONE person who's unhappy with distribute.)
I've posted now because Distutils-SIG for some time was a peaceful place again, then a thread started a new unuseful flame again.
On a separate note, I'm curious why discussion of Distutils2 development is not in a formal Python SIG, such as the Distutils-SIG.
To avoid such threads and flames. I am moderating the list over there because I don't want the ambiance to become as bad as distutils-SIG. I am not the maintainer of Distutils-SIG, and I am just making some suggestions to try to improve the situation. I would like the GSOC student to work in a friendly environment and not have them to deal with annoying threads. They are sending mails at distutils-SIG from time to time, but the work happens there. Maybe the list will disappear at some point if distutils-SIG become a friendlier place. You are welcome to join and work with us on distutils2 there,
Am 02.07.2010 16:13, schrieb Tarek Ziadé:
On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje@telecommunity.com> wrote: [..]
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools?
There's a huge gap between criticism + discussion, and the habitual flame of distribute vs setuptools. I think you know what I mean.
Feel free to propose some changes on these rules, because I think you would be as happy as I would not to have to deal with flames like that.
Tarek, as a more or less neutral observer, I have to agree that you seem to react a bit sensitive to anything that could be construed as a flame against distribute or the decision to fork. I know the reasons for that decision, and I probably would have done the same, but you need to be aware that there is always irritation in the community when such a disruptive fork happens, and no small part of that irritation is directed against the newcomer. I would try to see this list as on-topic for both distribute and setuptools, and let each maintainer/group handle the discussion about his/their tool. Trying to set up rules for this list isn't helpful; even if your rules don't seem like rules, but facts to me. In this case, Anatoly's suggestion to codify them in a sort of FAQ document and post them on the web or regularly here seems like a good one. cheers, Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Fri, Jul 2, 2010 at 5:44 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 02.07.2010 16:13, schrieb Tarek Ziadé:
On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje@telecommunity.com> wrote: [..]
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools?
There's a huge gap between criticism + discussion, and the habitual flame of distribute vs setuptools. I think you know what I mean.
Feel free to propose some changes on these rules, because I think you would be as happy as I would not to have to deal with flames like that.
Tarek, as a more or less neutral observer, I have to agree that you seem to react a bit sensitive to anything that could be construed as a flame against distribute or the decision to fork.
Probaly so, that's why I would like PJE to help building that FAQ, just to make sure it's not biased. Because you have to admit that the flames here, whether they are directed to distribute or setuptools, are unnecessary pain, and higher than in other lists. My intent to make rules so Distutils-SIG is peaceful, is a benefit for all parties.
I know the reasons for that decision, and I probably would have done the same, but you need to be aware that there is always irritation in the community when such a disruptive fork happens, and no small part of that irritation is directed against the newcomer. I would try to see this list as on-topic for both distribute and setuptools, and let each maintainer/group handle the discussion about his/their tool.
Trying to set up rules for this list isn't helpful; even if your rules don't seem like rules, but facts to me. In this case, Anatoly's suggestion to codify them in a sort of FAQ document and post them on the web or regularly here seems like a good one.
I agree, let's build this.
Am 02.07.2010 18:01, schrieb Tarek Ziadé:
On Fri, Jul 2, 2010 at 5:44 PM, Georg Brandl <g.brandl@gmx.net> wrote:
Am 02.07.2010 16:13, schrieb Tarek Ziadé:
On Fri, Jul 2, 2010 at 4:00 PM, P.J. Eby <pje@telecommunity.com> wrote: [..]
Isn't it interesting how these rules prohibit open disagreement or criticism (or even discussion!) of distribute and related matters, but *not* setuptools?
There's a huge gap between criticism + discussion, and the habitual flame of distribute vs setuptools. I think you know what I mean.
Feel free to propose some changes on these rules, because I think you would be as happy as I would not to have to deal with flames like that.
Tarek, as a more or less neutral observer, I have to agree that you seem to react a bit sensitive to anything that could be construed as a flame against distribute or the decision to fork.
Probaly so, that's why I would like PJE to help building that FAQ, just to make sure it's not biased.
That's a good idea!
Because you have to admit that the flames here, whether they are directed to distribute or setuptools, are unnecessary pain, and higher than in other lists.
Well, every list has its own problem, look at python-dev... Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Sat, Jul 3, 2010 at 12:44 AM, Georg Brandl <g.brandl@gmx.net> wrote:
I know the reasons for that decision, and I probably would have done the same
Shall I understand that the hijacking of setuptools by distribute (instead of merely forking it under a new name, which I don't care about) is sanctioned by python-dev ? If so, it should be written somewhere, and justified, because it impacts people who don't even use the software. David
[David Cournapeau]
[Georg Brandl]>
I know the reasons for that decision, and I probably would have done the same Shall I understand that the hijacking of setuptools by distribute (instead of merely forking it under a new name, which I don't care about) is sanctioned by python-dev ?
Setuptools is not a python-dev project, ergo python-dev has no official position on it. Georg is speaking for himself, albeit with the credit of his involvement in python-dev. FTR, when some extreme distribute fans proposed that the PyPI setuptools entry had to be given to distribute, people (including Guido if my memory’s not failing) sternly replied that this was rude and unwelcome. As already stated elsewhere more than once, the fact that distribute provides the setuptools Python package is a technical requirement. Regards
On Sat, Jul 3, 2010 at 3:10 PM, Éric Araujo <merwok@netwok.org> wrote:
FTR, when some extreme distribute fans proposed that the PyPI setuptools entry had to be given to distribute, people (including Guido if my memory’s not failing) sternly replied that this was rude and unwelcome.
As already stated elsewhere more than once, the fact that distribute provides the setuptools Python package is a technical requirement.
Ah, sorry about that, I missed it. What is that technical requirement ? David
As already stated elsewhere more than once, the fact that distribute provides the setuptools Python package is a technical requirement. Ah, sorry about that, I missed it. What is that technical requirement ?
Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes. Regards
On Sat, Jul 3, 2010 at 3:24 PM, Éric Araujo <merwok@netwok.org> wrote:
As already stated elsewhere more than once, the fact that distribute provides the setuptools Python package is a technical requirement. Ah, sorry about that, I missed it. What is that technical requirement ?
Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes.
That's not a technical requirement in any sense of the word. David
Éric Araujo wrote:
Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes.
But is there a technical reason why it *has* to be a drop-in replacement, as opposed to a different package with a different name? -- Greg
On Sat, Jul 3, 2010 at 9:32 AM, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Éric Araujo wrote:
Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes.
But is there a technical reason why it *has* to be a drop-in replacement, as opposed to a different package with a different name?
This technical reason was already explained in this mailing list back then, many times. Maybe you could read back the relevant threads for more details.
On Sat, Jul 3, 2010 at 5:06 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This technical reason was already explained in this mailing list back then, many times.
Maybe a link would be useful, so that it could referenced somewhere on distribute main page ? David
On Sat, Jul 3, 2010 at 12:29 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Jul 3, 2010 at 5:06 PM, Tarek Ziadé <ziade.tarek@gmail.com> wrote:
This technical reason was already explained in this mailing list back then, many times.
Maybe a link would be useful, so that it could referenced somewhere on distribute main page ?
Yes, as Anatoly suggested, I'll write a Packaging FAQ page, with this point contained. Probably in the HHG2P project
David
-- Tarek Ziadé | http://ziade.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greg Ewing wrote:
Éric Araujo wrote:
Distribute is a fork of Setupools, so it wants to be a drop-in replacement, i.e. to be used instead of setuptools with very few code changes.
But is there a technical reason why it *has* to be a drop-in replacement, as opposed to a different package with a different name?
The core issue is that distribute was intended to be useful for installing the hundreds / thousands of distribtions on PyPI which contain the line: from setuptools import setup and do so because they express dependencies and other metadata which the stock distutils version of setup() would choke on. Unless the site manager could arrange to have distribute install the 'setuptools' *package* on sys.path, distribute would have been a pointless fork. I can't comment on reasons why the project (*not* the package) might grab the 'setuptools' *project* name, as I don't use distribute itself. I don't know how much, if any, of the issue might be with the particular Debuntu packaging, either, as I never use the system python for my projects. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkwva74ACgkQ+gerLs4ltQ4OnwCg0lRgCLTmbeBUZMFH7Bw/tXVz GWkAn2twkgnfyqh0MUi1kZOMRPCufcZE =sTyl -----END PGP SIGNATURE-----
On Sat, Jul 3, 2010 at 3:10 PM, Éric Araujo <merwok@netwok.org> wrote:
[David Cournapeau]
[Georg Brandl]>
I know the reasons for that decision, and I probably would have done the same Shall I understand that the hijacking of setuptools by distribute (instead of merely forking it under a new name, which I don't care about) is sanctioned by python-dev ?
Setuptools is not a python-dev project, ergo python-dev has no official position on it. Georg is speaking for himself, albeit with the credit of his involvement in python-dev.
FTR, when some extreme distribute fans proposed that the PyPI setuptools entry had to be given to distribute, people (including Guido if my memory’s not failing) sternly replied that this was rude and unwelcome.
I fail to see the difference with the present situation. easy_install setuptools gives distribute, yolk -T src -F gives distribute. Distribute is the only fork I have seen in my entire life as an open source contributor which does this. When the cython people forked pyrex, they called their fork another name, and the script had another name. Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad. David
On Sat, Jul 3, 2010 at 5:23 PM, David Cournapeau <cournape@gmail.com> wrote:
On Sat, Jul 3, 2010 at 3:10 PM, Éric Araujo <merwok@netwok.org> wrote:
[David Cournapeau]
[Georg Brandl]>
I know the reasons for that decision, and I probably would have done the same Shall I understand that the hijacking of setuptools by distribute (instead of merely forking it under a new name, which I don't care about) is sanctioned by python-dev ?
Setuptools is not a python-dev project, ergo python-dev has no official position on it. Georg is speaking for himself, albeit with the credit of his involvement in python-dev.
FTR, when some extreme distribute fans proposed that the PyPI setuptools entry had to be given to distribute, people (including Guido if my memory’s not failing) sternly replied that this was rude and unwelcome.
I fail to see the difference with the present situation. easy_install setuptools gives distribute, yolk -T src -F gives distribute. Distribute is the only fork I have seen in my entire life as an open source contributor which does this. When the cython people forked pyrex, they called their fork another name, and the script had another name.
Besides the numerous technical issues, this is just basic decency. If I were PJE, I would be very mad.
Could you stop this now ? Obviously you didn't read back the threads, and didn't try to understand why we forked and the technicals details. You are just feeding the troll for the heck of it here, so stop it.
participants (7)
-
David Cournapeau -
Georg Brandl -
Greg Ewing -
P.J. Eby -
Tarek Ziadé -
Tres Seaver -
Éric Araujo