I want to suggest two changes to the standard release process: 1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use. 2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
I want to suggest two changes to the standard release process:
1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use.
The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users.
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py.
Is there something zc.buildout or setuptools can do differently that will mitigate this? -- Benji York Senior Software Engineer Zope Corporation
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
I want to suggest two changes to the standard release process:
1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use.
The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users.
It was introduced in the last release of 2.4. As far as I know there are no plans to make a new 2.4 point release.
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py.
Is there something zc.buildout or setuptools can do differently that will mitigate this?
I don't know I'm afraid. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Apr 22, 2009, at 10:55 AM, Wichert Akkerman wrote: ...
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py.
Is there something zc.buildout or setuptools can do differently that will mitigate this?
I don't know I'm afraid.
Perhaps you could provide (or point to) an example that illustrates this problem. Jim -- Jim Fulton Zope Corporation
On 4/22/09 4:57 PM, Jim Fulton wrote:
Perhaps you could provide (or point to) an example that illustrates this problem.
I want to keep my python install clean, so I do not have setuptools installed system-wide. Instead I have a small bin-directory managed by buildout which creates a python interpreter with setuptools, using this snippet: [setuptools] recipe = zc.recipe.egg interpreter = spython eggs = setuptools scripts = spython That allows me to use "spython setup.py sdist register upload". setup.py is invoked with __file__ pointing to the spython wrapper script, so any attempt in setup.py to use __file__ to found files will fail. Wichert.=
On Apr 22, 2009, at 11:01 AM, Wichert Akkerman wrote:
On 4/22/09 4:57 PM, Jim Fulton wrote:
Perhaps you could provide (or point to) an example that illustrates this problem.
I want to keep my python install clean, so I do not have setuptools installed system-wide. Instead I have a small bin-directory managed by buildout which creates a python interpreter with setuptools, using this snippet:
[setuptools] recipe = zc.recipe.egg interpreter = spython eggs = setuptools scripts = spython
That allows me to use "spython setup.py sdist register upload". setup.py is invoked with __file__ pointing to the spython wrapper script, so any attempt in setup.py to use __file__ to found files will fail.
This sounds like a bug in interpreter-script's handling of scripts passed to it. I'll look into that. BTW, did you realize that buildout has a setup command that does what your spython script does (and a little more)? Jim -- Jim Fulton Zope Corporation
On 4/22/09 5:05 PM, Jim Fulton wrote:
On Apr 22, 2009, at 11:01 AM, Wichert Akkerman wrote:
On 4/22/09 4:57 PM, Jim Fulton wrote:
Perhaps you could provide (or point to) an example that illustrates this problem.
I want to keep my python install clean, so I do not have setuptools installed system-wide. Instead I have a small bin-directory managed by buildout which creates a python interpreter with setuptools, using this snippet:
[setuptools] recipe = zc.recipe.egg interpreter = spython eggs = setuptools scripts = spython
That allows me to use "spython setup.py sdist register upload". setup.py is invoked with __file__ pointing to the spython wrapper script, so any attempt in setup.py to use __file__ to found files will fail.
This sounds like a bug in interpreter-script's handling of scripts passed to it. I'll look into that.
Thanks
BTW, did you realize that buildout has a setup command that does what your spython script does (and a little more)?
I was not aware of that. I can see that being useful. Most of my packages do not have their own buildout, so this won't help much for this particular issue I'm afraid. Wichert. -- Wichert Akkerman<wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
I want to suggest two changes to the standard release process:
1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use.
The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users.
It was introduced in the last release of 2.4. As far as I know there are no plans to make a new 2.4 point release.
That is most unfortunate. Maybe we should officially drop 2.4 support instead. -- Benji York Senior Software Engineer Zope Corporation
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:55 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
Previously Benji York wrote:
On Wed, Apr 22, 2009 at 10:06 AM, Wichert Akkerman <wichert@wiggy.net> wrote:
I want to suggest two changes to the standard release process:
1. use "sdist --formats=zip". This works around a nasty bug in the python 2.4 tarfile module which makes it skip files with a path of a specific length. This can make a release impossible to use.
The bug you refer to is indeed nasty, but (IIRC) was fixed in later releases of 2.4. I'd rather not add yet another thing people have to remember to do to make a release for the benefit of such a small minority of end-users.
It was introduced in the last release of 2.4. As far as I know there are no plans to make a new 2.4 point release.
That is most unfortunate.
Maybe we should officially drop 2.4 support instead.
Unfortuantely there is a large group of people using Plone on Zope 2.10 who can not upgrade to a newer python version, and they are very interesting in the Zope Toolkit candy. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Hey, Wichert Akkerman wrote: [snip]
Unfortuantely there is a large group of people using Plone on Zope 2.10 who can not upgrade to a newer python version, and they are very interesting in the Zope Toolkit candy.
Are Zope 2.10 users interested in using *recent* releases of the Zope Toolkit packages? Or are they just using Zope 3.3 or Zope 3.4? I am hoping that Zope 2.10 won't be a platform where more recent toolkit packages are in use or are going to be in use. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Am 22.04.2009 um 17:42 schrieb Martijn Faassen:
Hey,
Wichert Akkerman wrote: [snip]
Unfortuantely there is a large group of people using Plone on Zope 2.10 who can not upgrade to a newer python version, and they are very interesting in the Zope Toolkit candy.
Are Zope 2.10 users interested in using *recent* releases of the Zope Toolkit packages? Or are they just using Zope 3.3 or Zope 3.4?
All Zope 2 versions are tied to a particular Zope 3.X version. There are little chances mixing different versions without issues. Andreas - --- ZOPYX Ltd. & Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany Web: www.zopyx.com - Email: info@zopyx.com - Phone +49 - 7071 - 793376 Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535 Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK - ------------------------------------------------------------------------ E-Publishing, Python, Zope & Plone development, Consulting -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Darwin) iEYEARECAAYFAknvRvYACgkQCJIWIbr9KYxlIACgqLkvd0DIJc42kndq6u3ZaEtR vzMAn1W4aavU4GC0EmUZcDYs+MB8LfcT =xRku -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Wichert Akkerman wrote:
Unfortuantely there is a large group of people using Plone on Zope 2.10 who can not upgrade to a newer python version, and they are very interesting in the Zope Toolkit candy.
They shouldn't be: there is no way we are going to be able to keep pre-2.12 users happy over the long run. At this point, running Zope 2.10 is like running Debian etch: "Stability or goodies, pick one." - -1 to adding any constraints on the ZTK FBO older Zope 2 releases. 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.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJ7z6t+gerLs4ltQ4RAsKCAJ4nwh0Q3a/zOgWbvvdbm91FauuwLgCfWmC2 xL2bS1eXF5qeBLZP0z9CIe8= =OXVp -----END PGP SIGNATURE-----
Hey, Benji York wrote: [snip]
Maybe we should officially drop 2.4 support instead.
I'm +1 on dropping 2.4 support for new releases of Zope Toolkit packages. As soon as Grok 1.0 is released I'm fine with dropping support for 2.4 in future releases of Grok as well. Of course we do still have maintenance releases to worry about, but those would typically rely on older versions of the Zope Toolkit packages anyway. Regards, Martijn
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py.
This will break many setup.py scripts that use __file__ to integrate README.txt and such for publication on pypi. I think that's a useful feature we cannot just drop, so hopefully there's another solution. Regards, Martijn
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py.
This will break many setup.py scripts that use __file__ to integrate README.txt and such for publication on pypi. I think that's a useful feature we cannot just drop, so hopefully there's another solution.
Can we assume that the cwd is the root of the package? Do you ever invoke setup.py from somewhere else? All Plone packages make that assumption and we've never seen any problems with it. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman wrote:
Can we assume that the cwd is the root of the package?
You can assume whatever you like, the problem is when other people assume something different ;-) There's no *need* to make this assumption... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
On 4/22/09 4:13 PM, Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py. This will break many setup.py scripts that use __file__ to integrate README.txt and such for publication on pypi. I think that's a useful feature we cannot just drop, so hopefully there's another solution.
Can we assume that the cwd is the root of the package? Do you ever invoke setup.py from somewhere else? All Plone packages make that assumption and we've never seen any problems with it.
You actually can't anyway (at least currently, for any useful setup.py command): http://plope.com/Members/chrism/setup.py-blues - C
Folks, Stop talking about this. :) This is almost certainly a buildout bug that I'll fix. Jim On Apr 22, 2009, at 5:40 PM, Chris McDonough wrote:
On 4/22/09 4:13 PM, Wichert Akkerman wrote:
Previously Martijn Faassen wrote:
Wichert Akkerman wrote:
2. forbid the use of __file__ in setup.py. This breaks on systems which do not have setuptools installed globally but rely on a (zc.buildout-created) wrapper script. __file__ will point to the wrapper script in those instances, which breaks setup.py. This will break many setup.py scripts that use __file__ to integrate README.txt and such for publication on pypi. I think that's a useful feature we cannot just drop, so hopefully there's another solution.
Can we assume that the cwd is the root of the package? Do you ever invoke setup.py from somewhere else? All Plone packages make that assumption and we've never seen any problems with it.
You actually can't anyway (at least currently, for any useful setup.py command):
http://plope.com/Members/chrism/setup.py-blues
- C _______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
-- Jim Fulton Zope Corporation
Hey Jim, others, Jim Fulton wrote: [__file__ in setup.py]
Stop talking about this. :)
This is almost certainly a buildout bug that I'll fix.
Just making sure we have some clear conclusions in this thread... Do we have a buildout bug id we can track so we make sure we don't forget about it? (if it wasn't already fixed?) The other issue involved using --zip to retain compatibility with Python 2.4. There was some back and forth about this. I will bring up the whole issue of Python 2.4 support in Zope Toolkit packages in a new thread. Regards, Martijn
Previously Martijn Faassen wrote:
Hey Jim, others,
Jim Fulton wrote:
[__file__ in setup.py]
Stop talking about this. :)
This is almost certainly a buildout bug that I'll fix.
Just making sure we have some clear conclusions in this thread...
Do we have a buildout bug id we can track so we make sure we don't forget about it? (if it wasn't already fixed?)
There is now: https://bugs.launchpad.net/zc.buildout/+bug/368447 Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
Martijn Faassen wrote:
This will break many setup.py scripts that use __file__ to integrate README.txt and such for publication on pypi. I think that's a useful feature we cannot just drop, so hopefully there's another solution.
Yeah, I do this a lot *and* use buildout so don't have setuptoosl installed system-wide. I guess because I use "bin/builout setup setup.py bah" I've never had any problems... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
participants (8)
-
Andreas Jung -
Benji York -
Chris McDonough -
Chris Withers -
Jim Fulton -
Martijn Faassen -
Tres Seaver -
Wichert Akkerman