Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Mon, Oct 19, 2009 at 4:35 AM, Steve Steiner sstei...@mac.com wrote: http://pastebin.com/m69796bc5 sounds like version problems. This is running on a bare system, after figuring out which development tools were needed, all the version control systems necessary etc. I have all that captured in my Fabric script so we're all set for being able to duplicate it. I have NOT installed anything into the system Python at all. In fact, other than the tools necessary to pull the products out of VCS, and the compilers and such, I haven't installed (or done) anything to the system at all. That's kind of the point. We want to be able to go from bare metal to running buildbot completely automatically. I tried to build the buildbot again on debian and Mac OSX and it worked fine Didn't try on Ubuntu though. It seems that it's using the buildbot installed in your system, which might be the problem since the buildout doesn't pinpoint the versions. Here, I use Python 2.6 and I have: - buildbot-0.7.11p3 - Twisted-8.2.0 - collective.buildbot-0.3.5 I suggest that you install virtualenv and that your run this sequence in an Ubuntu that has all the development tools we have discussed (python-dev, zlib, etc) : $ cd /var/ $ mkdir distutils-bot $ cd distutils-bot $ virtualenv --no-site-packages . $ hg clone https://ta...@bitbucket.org/tarek/distutils-builbot . $ bin/python bootstrap.py $ bin/buildout -c buildbot.cfg This is supposed to compile. Last option: give me an ssh access to your ubuntu box if possible, I'll probaby be able to fix it. Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Mon, Oct 19, 2009 at 9:34 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: I tried to build the buildbot again on debian and Mac OSX and it worked fine Didn't try on Ubuntu though. Here's this very buildbot running on debian: http://ziade.org:9080/waterfall ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
On Sat, Oct 17, 2009 at 06:00:51PM -0400, David Lyon wrote:
On Sat, 17 Oct 2009 18:19:44 +0200, Tarek Ziadé ziade.ta...@gmail.com
wrote:
e.g. like = 'KDEDIR' in os.environ (so meaning we introduce sequence
comparisons/operators
in those markers)
[...]
For example, if there is a /etc/gdm/gdm.conf it is pretty safe
to assume that gnome is installed on that system.
So in your PEP, your could have code..
if sys.platform == 'linux2':
gnome_installed = os.path.exists('/etc/gdm/gdm.conf')
Then exposed that as a variable in your condition:
'if desktop in gnome|windows' etc
All this seems like a bad idea to me. Thinking from a GNU/Linux
distro point of view now you'd need to add a build-depends to e.g. GDM
*and* KDM only to get the correct .desktop file or something like
that. And even worse, as proposed it would probably get confused when
both are installed.
There must be better ways of saying if you want to have (e.g.) a
.desktop file installed.
Also the choice you give to a Python package author is suddenly
massive: linux-gnome-kde-32-whatever. Just how is a Python package
author supposed to get this right?
Regards
Floris
--
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
On Mon, 19 Oct 2009 10:18:57 +0100, Floris Bruynooghe floris.bruynoo...@gmail.com wrote: All this seems like a bad idea to me. Thinking from a GNU/Linux distro point of view now you'd need to add a build-depends to e.g. GDM *and* KDM only to get the correct .desktop file or something like that. And even worse, as proposed it would probably get confused when both are installed. I don't see why. An application/package might use KDE and might want to check for it. An application/package might want to use GNOME and want to check for it. Why can't developers check what the platform is? There's no forcing developers to use these checks. They're only there to assist in overcoming platform specific installation issues. There must be better ways of saying if you want to have (e.g.) a .desktop file installed. Ok.. so throw me some ideas.. Also the choice you give to a Python package author is suddenly massive: linux-gnome-kde-32-whatever. Just how is a Python package author supposed to get this right? Typically, the don't specify anything. They just assume everything works on every platform until their test process tells them it isn't so. In that case, this mechanism allows them to provide workarounds for problem cases. I cannot see how that is a bad idea... David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
On Sun, Oct 18, 2009 at 12:00 AM, David Lyon david.l...@preisshare.net wrote:
So in your PEP, your could have code..
if sys.platform == 'linux2':
gnome_installed = os.path.exists('/etc/gdm/gdm.conf')
Then exposed that as a variable in your condition:
'if desktop in gnome|windows' etc
From the stdlib PoV, exposing new variables like gnome isn't
appropriate, because
we don't want to keep track of all desktop systems in the stdlib.
That's impossible.
So we have to work at providing tools for the developers in the
conditions, for them
to express them.
So exposing os.environ for your use case could help. I am not sure
about file presence though.
More generally, I feel uncomfurtable to give too much power in the
PKG-INFO syntax, I think
things like os.platform() are enough to describe conditional fields in
the metadata.
I can see a use case for building Extensions and package_data etc..
But what is the use case to detect gnome for the metadata fields ?
Tarek
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Mon, Oct 19, 2009 at 1:44 PM, Steve Steiner sstei...@mac.com wrote: The whole idea here is to make a setup script that sets the machine: Fire up a new cloud server Install whatever software is necessary Download the buildbot code Build the buildbot Start it running for as long as needed Kill the server We pay for the server by the hour (1.5 cents/hr) and can fire up as many as necessary. I will put my fabric script up on bitbucket in my clone and you can pull it over and see what I mean. Right now, Im just using a local VM, but the idea would be to put a fresh one up on Rackspace as needed, then kill when done. Sounds good. $ cd /var/ $ mkdir distutils-bot $ cd distutils-bot $ virtualenv --no-site-packages . $ hg clone https://ta...@bitbucket.org/tarek/distutils-builbot . $ bin/python bootstrap.py $ bin/buildout -c buildbot.cfg This is supposed to compile. Last option: give me an ssh access to your ubuntu box if possible, I'll probaby be able to fix it. I am not looking to hand-fix this, that would be pointless. I want an automated build script that will fire up a brand new Ubuntu cloud server, set up the entire environment, install the buildbot and run. By fix it I mean debugging it in your environment to find the problem of course. Anyways, let see what my sequence does in your VM (with python-dev installed first, and zlib) And if it fails, ls me the content of eggs/ as well Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Brand new, clean server, set up from scratch, buildbot still fails
http://pastebin.com/m69796bc5 This is running on a bare system, after figuring out which development tools were needed, all the version control systems necessary etc. I have all that captured in my Fabric script so we're all set for being able to duplicate it. I have NOT installed anything into the system Python at all. In fact, other than the tools necessary to pull the products out of VCS, and the compilers and such, I haven't installed (or done) anything to the system at all. That's kind of the point. We want to be able to go from bare metal to running buildbot completely automatically. I don't quite understand what this thing is supposed to be doing but I'm sure it's not doing everything it needs to do to get itself bootstrapped; on a fresh Ubuntu install, anyway. BTW, on my OS X development system, running the system Python 2.6.1, it doesn't have any trouble at all except for this little gem early in the process. /usr/bin/python -c from setuptools.command.easy_install import main; main() -mUNxd /Users/ssteiner/Dropbox/work/distutils-builbot/ eggs/tmptMBdZk -q /Users/ssteiner/Dropbox/src/twisted_trunk path=/Users/ssteiner/Dropbox/work/distutils-builbot/eggs/ setuptools-0.6c9-py2.6.egg /Library/Python/2.6/site-packages/Pyrex-0.9.8.5-py2.6.egg/Pyrex/ Compiler/Errors.py:17: DeprecationWarning: BaseException.message has been deprecated as of Python 2.6 self.message = message unrecognized .svn/entries format in conftest.c:1:23: error: sys/epoll.h: No such file or directory conftest.c:1:23: error: sys/epoll.h: No such file or directory conftest.c:1:23: error: sys/epoll.h: No such file or directory lipo: can't open input file: /var/folders/28/28Xggq0cGXqLpT1Uz5Gk4E++ +TI/-Tmp-//ccOmCair.out (No such file or directory) Got Twisted 8.2.0-r27376. Picked: Twisted = 8.2.0-r27376 Getting required 'zope.interface' required by collective.buildbot 0.3.5. required by Twisted 8.2.0-r27376. ... and then it carries on. However, when trying to run it with /bin/test, something tries to refer to trunk-checkout when the python trunk was actually checked out into python-trunk. (~/work/distutils-builbot)# bin/test Traceback (most recent call last): File bin/test, line 12, in module os.chdir(python_trunk) OSError: [Errno 2] No such file or directory: '/Users/ssteiner/work/ distutils-builbot/parts/trunk-checkout/python' All in all, I really can't get it to build or run anywhere at this point... S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Oct 19, 2009, at 3:36 AM, Tarek Ziadé wrote: On Mon, Oct 19, 2009 at 9:34 AM, Tarek Ziadé ziade.ta...@gmail.com wrote: I tried to build the buildbot again on debian and Mac OSX and it worked fine Didn't try on Ubuntu though. Here's this very buildbot running on debian: http://ziade.org:9080/waterfall I'm not disputing that it runs, I'm telling you that it won't run on a clean Ubuntu without some additional setup. S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
On Mon, 19 Oct 2009 13:46:11 +0200, Tarek Ziadé ziade.ta...@gmail.com wrote: From the stdlib PoV, exposing new variables like gnome isn't appropriate, because we don't want to keep track of all desktop systems in the stdlib. That's impossible. Well, the list isn't infinite. And under Linux there are only two major ones existing in any great quantity unless I am mistaken. They are Gnome and KDE. The rest.. aren't so important for detection I would suggest.. ok - somebody stick a stake in my heart... haha So exposing os.environ for your use case could help. I am not sure about file presence though. As I said before.. I'm not so keen on that. More generally, I feel uncomfurtable to give too much power in the PKG-INFO syntax, I think things like os.platform() are enough to describe conditional fields in the metadata. But what is the use case to detect gnome for the metadata fields ? Perphaps somebody is writing something that only works in gnome. The true rational is slightly different. Under windows there are distinct window manager versions. Eg XP, Vista, Windows 7, win-ce. They *do* have a big impact on python programs and change configurations significantly. So my rationale is simply to have the same thing under linux where there are two major desktops, KDE and GNOME. Maybe on the Mac there are differences to the python developer and we shouldn't forget those also. I'm proposing detecting less than 10 different desktops in all. And detecting those with two lines of code each. So 20 lines of code.. About 20 lines of new code shouldn't be so hard... I would have thought. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from sc ratch, buildbot still fails
On Mon, 19 Oct 2009 07:44:56 -0400, Steve Steiner sstei...@mac.com wrote: I am not looking to hand-fix this, that would be pointless. I want an automated build script that will fire up a brand new Ubuntu cloud server, set up the entire environment, install the buildbot and run. Can I help? It's actually a pretty interesting and typical problem. One of the big challenges is spanning the internal reach of python packaging to 'the outside'. I wish I could use a mac - where we don't have these problems. But under Linux, even on a good distro like debian or ubuntu, it can take a while to locate all the compilers and external tools that are required to build your given package. Doing 'fresh' installs on a fresh os surely is a typical developer use case... or should be going forward.. It should be pretty simple to specify external os-packages and pull them in. Somehow.. :-) (apt-get) There must be some way to put these into a coherent config file. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Oct 19, 2009, at 8:57 AM, David Lyon wrote: On Mon, 19 Oct 2009 07:44:56 -0400, Steve Steiner sstei...@mac.com wrote: I am not looking to hand-fix this, that would be pointless. I want an automated build script that will fire up a brand new Ubuntu cloud server, set up the entire environment, install the buildbot and run. Can I help? I've just put the fabfile up in the distutils-buildbot http://bitbucket.org/tarek/distutils-buildbot/overview/ Feel free to jump in! I've run that exact fabfile onto a pure fresh ubuntu 9.04 setup and it won't run yet. Any insight you can provide would be much appreciated. I'd love to make a make me a buildbot tool; I think it would be incredibly useful, generally. S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Mon, Oct 19, 2009 at 3:23 PM, Steve Steiner sstei...@mac.com wrote: On Oct 19, 2009, at 8:57 AM, David Lyon wrote: On Mon, 19 Oct 2009 07:44:56 -0400, Steve Steiner sstei...@mac.com wrote: I am not looking to hand-fix this, that would be pointless. I want an automated build script that will fire up a brand new Ubuntu cloud server, set up the entire environment, install the buildbot and run. Can I help? I've just put the fabfile up in the distutils-buildbot http://bitbucket.org/tarek/distutils-buildbot/overview/ Feel free to jump in! I've run that exact fabfile onto a pure fresh ubuntu 9.04 setup and it won't run yet. Any insight you can provide would be much appreciated. I'd love to make a make me a buildbot tool; I think it would be incredibly useful, generally. Beware that for the server part of buildbot, it doesn't work on Windows, Maybe this has changed but that's the last status I know of. But I definitely want to run the slaves on Win32. This would require the buildout to make the distinction between a slave machine and a machine that has a salve and a master. It' not the case right now but I can change it, by adding a 'only_slave.cfg' file Tarek ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Brand new, clean server, set up from scratch, buildbot still fails
On Oct 19, 2009, at 9:29 AM, Tarek Ziadé wrote: But I definitely want to run the slaves on Win32. How about we get it running, first... ;-) S ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] [buildout] Fixed verbose mode when developing eggs
Hello,
I had a small headache using Buildout this morning: I had a package which
contained a C extension and which was developed in my buildout.cfg file. I
wanted to see what was the gcc call used to build this extension, but using
as much as -v as I could (I stopped at ten), I didn't see anything more.
So, I dig in the code, and there was a typo in easy_install.py, which is
fixed in fix-verbose-develop.patch (this needs a test to be updated, BTW).
The fix was trivial (replacing == with =), but I think the way args is
build is now better.
I propose also another patch (uniformize-args.patch), which refactors args
construction using a list instead of a tuple, which looks smarter (why a
tuple whereas it is updated several times?).
This is not mandatory for the fix, feel free to integrate it or not.
Cheers,
JonathanIndex: src/zc/buildout/tests.py
===
--- src/zc/buildout/tests.py(révision 105143)
+++ src/zc/buildout/tests.py(copie de travail)
@@ -90,7 +90,7 @@
Installing...
Develop: '/sample-buildout/foo'
in: '/sample-buildout/foo'
-... -q develop -mxN -d /sample-buildout/develop-eggs/...
+... -v develop -mxN -d /sample-buildout/develop-eggs/...
Index: src/zc/buildout/easy_install.py
===
--- src/zc/buildout/easy_install.py (révision 105143)
+++ src/zc/buildout/easy_install.py (copie de travail)
@@ -873,18 +873,16 @@
tmp3 = tempfile.mkdtemp('build', dir=dest)
undo.append(lambda : shutil.rmtree(tmp3))
-args = [
-zc.buildout.easy_install._safe_arg(tsetup),
-'-q', 'develop', '-mxN',
-'-d', _safe_arg(tmp3),
-]
-
+args = [zc.buildout.easy_install._safe_arg(tsetup)]
log_level = logger.getEffectiveLevel()
-if log_level = 0:
-if log_level == 0:
-del args[1]
-else:
-args[1] == '-v'
+if log_level 0:
+args.append('-v')
+elif log_level 0:
+args.append('-q')
+
+args.extend(['develop', '-mxN',
+ '-d', _safe_arg(tmp3)])
+
if log_level logging.DEBUG:
logger.debug(in: %r\n%s, directory, ' '.join(args))
diff -u src/zc/buildout/easy_install.py src/zc/buildout/easy_install.py
--- src/zc/buildout/easy_install.py (copie de travail)
+++ src/zc/buildout/easy_install.py (copie de travail)
@@ -301,16 +301,16 @@
ws, False,
)[0].location
-args = ('-c', _easy_install_cmd, '-mUNxd', _safe_arg(tmp))
+args = ['-c', _easy_install_cmd, '-mUNxd', _safe_arg(tmp)]
if self._always_unzip:
-args += ('-Z', )
+args.append('-Z')
level = logger.getEffectiveLevel()
if level 0:
-args += ('-q', )
+args.append('-q')
elif level 0:
-args += ('-v', )
+args.append('-v')
-args += (_safe_arg(spec), )
+args.append(_safe_arg(spec))
if level = logging.DEBUG:
logger.debug('Running easy_install:\n%s %s\npath=%s\n',
@@ -319,13 +319,13 @@
if is_jython:
extra_env = dict(os.environ, PYTHONPATH=path)
else:
-args += (dict(os.environ, PYTHONPATH=path), )
+args.append(dict(os.environ, PYTHONPATH=path))
sys.stdout.flush() # We want any pending output first
if is_jython:
exit_code = subprocess.Popen(
-[_safe_arg(self._executable)] + list(args),
+[_safe_arg(self._executable)] + args,
env=extra_env).wait()
else:
exit_code = os.spawnle(
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [buildout] Fixed verbose mode when developing eggs
On Mon, Oct 19, 2009 at 11:11 AM, Jonathan Ballet j...@multani.info wrote: Hello, I had a small headache using Buildout this morning: I had a package which contained a C extension and which was developed in my buildout.cfg file. I wanted to see what was the gcc call used to build this extension, but using as much as -v as I could (I stopped at ten), I didn't see anything more. So, I dig in the code, and there was a typo in easy_install.py, which is fixed in fix-verbose-develop.patch (this needs a test to be updated, BTW). The fix was trivial (replacing == with =), but I think the way args is build is now better. I propose also another patch (uniformize-args.patch), which refactors args construction using a list instead of a tuple, which looks smarter (why a tuple whereas it is updated several times?). This is not mandatory for the fix, feel free to integrate it or not. Thanks. I'll apply this soon. :) Jim -- Jim Fulton ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] buglet in setuptools 0.6c10
Sorry for the lame-ass bug report, but my stack is really deep and I didn't want this one to go unreported. I just tried 0.6c10 to see if it would fix a problem I'm having. How fortunate that it hit Cheeseshop at just the right time ;). Unfortunately, there's a bug in setuptools/command/sdist.py Line 184 references string.join, but 'string' is undefined. -Barry signature.asc Description: PGP signature ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Setuptools 0.6c10 released
The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered site directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious already imported from another path warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious already imported warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==0.6c10. (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any problems with setuptools to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
At 03:33 PM 10/19/2009 -0400, Barry Warsaw wrote: Sorry for the lame-ass bug report, but my stack is really deep and I didn't want this one to go unreported. I just tried 0.6c10 to see if it would fix a problem I'm having. How fortunate that it hit Cheeseshop at just the right time ;). Unfortunately, there's a bug in setuptools/command/sdist.py Line 184 references string.join, but 'string' is undefined. -Barry Thanks; it's fixed and pushed back to PyPI. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
On Oct 19, 2009, at 3:55 PM, P.J. Eby wrote: At 03:33 PM 10/19/2009 -0400, Barry Warsaw wrote: Sorry for the lame-ass bug report, but my stack is really deep and I didn't want this one to go unreported. I just tried 0.6c10 to see if it would fix a problem I'm having. How fortunate that it hit Cheeseshop at just the right time ;). Unfortunately, there's a bug in setuptools/command/sdist.py Line 184 references string.join, but 'string' is undefined. -Barry Thanks; it's fixed and pushed back to PyPI. Thanks. -B PGP.sig Description: This is a digitally signed message part ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.6c10 released
P.J. Eby kirjoitti: The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python According to the notice on the setuptools bug tracker, you did this by avoiding the use of LoadLibraryEx(). I don't see any changes in launcher.c in setuptools SVN yet, did you forget to commit? Or am I looking in the wrong place? I'd like to see your solution. * Stop crashing on certain types of HTTP error * Stop re-trying URLs that already failed retrieval once * Fixes for various dependency management problems such as looping builds, re-downloading packages already present on sys.path (but not in a registered site directory), and randomly preferring local -f packages over local installed packages * Prevent lots of spurious already imported from another path warnings (e.g. when pkg_resources is imported late) * Ensure C libraries (as opposed to extensions) are also built when doing bdist_egg Other changes: * Misc. documentation fixes * Improved Jython support * Fewer warnings under Python 2.6+ * Warn when 'packages' uses paths instead of package names (because it causes other problems, like spurious already imported warnings) * Stop using /usr/bin/sw_vers on Mac OS (replaced w/'platform' module calls) You can install the updated version using easy_install (or pip!), asking for setuptools==0.6c10. (Note for users of Distribute: Distribute and setuptools use the same package name 'setuptools', and thus cannot both be present on the same sys.path (e.g. in the same virtualenv). If you wish to switch a given environment from Distribute to setuptools or vice versa, you will need to completely uninstall one before installing the other. If you currently have Distribute installed, please follow Distribute's uninstall instructions if you wish to reinstall setuptools.) Please report any problems with setuptools to the setuptools bug tracker at: http://bugs.python.org/setuptools/ For faster response to questions, please use the distutils-sig mailing list, rather than the tracker. Setuptools documentation can be found via links at http://pypi.python.org/pypi/setuptools#using-setuptools-and-easyinstall -- and the pages on the PEAK wiki now load much, much faster than they did a few months ago. (They're static cached pages now, rather than dynamically generated, unless you're actually logged into the wiki.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Setuptools 0.6c10 released
At 11:33 PM 10/19/2009 +0300, Alex Grönholm wrote: P.J. Eby kirjoitti: The long-overdue setuptools 0.6c10 update is now available on PyPI, at: http://pypi.python.org/setuptools/ Major updates and fixes include: * Support for SVN 1.6 and Python 2.6 * Fix for the Python 2.6.3 build_ext API change * Support for the most recent Sourceforge download link insanity * Fix for Vista UAC errors running easy_install.exe or other installer-looking executables * Fix for errors launching 64-bit Windows Python According to the notice on the setuptools bug tracker, you did this by avoiding the use of LoadLibraryEx(). I don't see any changes in launcher.c in setuptools SVN yet, did you forget to commit? It looks like I managed to revert it in my working copy, too. Crap. (Which is weird, because I know I built the executables before and tested them on a 64-bit Vista box.) I've reapplied the changes and put it back in SVN. 'easy_install setuptools==dev06' will let you get it for now. Or am I looking in the wrong place? I'd like to see your solution. I changed the loadable_exe() function to be a no-op string copy, essentially. Looks like I'll need to go ahead and put out a c11 tomorrow. Sorry about that. Thanks for the prompt report. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
[Distutils] Avoid dependency_links / find_links
Hi, We manage our projects with setuptools. For this we have a local PyPi mirror with just our required packages. This mirror is specified in our setuptools environments using the index_url directive. The basic idea is: we don't want to access the internet when installing packages. Today I had to realized that we haven't been reaching that goal as Pylons contains a dependency_links pointing to pylonshq.com. So the question would be: is there any way to avoid following any dependency_links and/or find_links paths and only use the index_url? I have quickly checked the setuptools source code and couldn't find any way to do this. Would a patch be accepted if I implemented that behavior? Are there other approaches to do what I'm trying to do? Thanks in advance Patrice ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Avoid dependency_links / find_links
At 12:02 AM 10/20/2009 +0200, Patrice Neff wrote: So the question would be: is there any way to avoid following any dependency_links and/or find_links paths and only use the index_url? Yes. See: http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts which explains how to use the command line or configuration files to control this. Also see: http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options under the '--allow-hosts' option for more details on the syntax. ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] Avoid dependency_links / find_links
On Oct 20, 2009, at 12:30 AM, P.J. Eby wrote: Yes. See: http://peak.telecommunity.com/DevCenter/EasyInstall#restricting-downloads-with-allow-hosts which explains how to use the command line or configuration files to control this. Also see: http://peak.telecommunity.com/DevCenter/EasyInstall#command-line-options under the '--allow-hosts' option for more details on the syntax. Thank you, this works great for my purpose. Sorry I missed that in the documentation. Patrice ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
On 2009-10-19, at 2055, P.J. Eby wrote: Thanks; it's fixed and pushed back to PyPI. With the same version number. What about the people who have already installed your broke 0.6c10 that don't read this list? Matt ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
Floris Bruynooghe wrote:
For example, if there is a /etc/gdm/gdm.conf it is pretty safe
to assume that gnome is installed on that system.
So in your PEP, your could have code..
if sys.platform == 'linux2':
gnome_installed = os.path.exists('/etc/gdm/gdm.conf')
Then exposed that as a variable in your condition:
'if desktop in gnome|windows' etc
Agreed, this is too fragile and complicated. Anyone who has done
packaging knows how fragile those things are: some buggy packages do not
remove some files, some corner cases you did not think about are always
coming.
At least for things like platform, arch and os, things are quite stable.
For everything else, either there is a way to define our own variable
whose values are handled by outside code (say setup.py or command line),
or you don't make them available at all in the static file. I don't see
other solution, and the packaging solutions I know do not allow this
kind of things. For any new feature in distutils, it should almost be
mandatory to look at what other people did to the same problem space.
Good design only comes with experience in that space domain, IMO.
David
___
Distutils-SIG maillist - Distutils-SIG@python.org
http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] buglet in setuptools 0.6c10
At 02:05 AM 10/20/2009 +0100, Matthew Wilkes wrote: On 2009-10-19, at 2055, P.J. Eby wrote: Thanks; it's fixed and pushed back to PyPI. With the same version number. What about the people who have already installed your broke 0.6c10 that don't read this list? They'll see an announcement for 0.6c11 tomorrow. I didn't want to bump the version number right away, in case there were any other problems. (And there were.) ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
Re: [Distutils] [RFC] Recentering the static metadata need : PKG-INFO
On Tue, 20 Oct 2009 12:41:52 +0900, David Cournapeau da...@ar.media.kyoto-u.ac.jp wrote: 'if desktop in gnome|windows' etc Agreed, this is too fragile and complicated. I don't understand which part is fragile. Detecting if gnome or windows exists? or implementing this via Tareks proposal (sort of shown as best as I understand it above). My proposal has always been: [dependencies windows] packages = win32com If you are really suggesting that detecting windows is so fragile that it really shouldn't be supported I really don't have much further to say. Windows is fragile... linux is fragile.. python packaging is fragile.. At least for things like platform, arch and os, things are quite stable. Ok, so you agree with everything up to defining the window manager. That's good. Detecting the actual window manager is a fairly trivial detail. In reality. For everything else, either there is a way to define our own variable whose values are handled by outside code (say setup.py or command line), or you don't make them available at all in the static file. I don't see other solution, and the packaging solutions I know do not allow this kind of things. For any new feature in distutils, it should almost be mandatory to look at what other people did to the same problem space. Good design only comes with experience in that space domain, IMO. I do many desktop software installs. I have a good working knowledge of the issues. Ok - I'm agreeing. So lets make all the python packaging as good as it is in perl. Really, you're only objection comes down to the tags 'gnome' and 'kde' if I'm not mistaken. To me they aren't big issues. Ok, so we have to ommit 4 lines of code. I'm not bothered. David ___ Distutils-SIG maillist - Distutils-SIG@python.org http://mail.python.org/mailman/listinfo/distutils-sig
