[Python-Dev] Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209
On 18-dec-04, at 21:48, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21493 Modified Files: setup.py Log Message: Switch from getting LDFLAGS and CPPFLAGS from the environment to the Makefile. This is to avoid a problem that inconsistently comes up where the environment variable is unset while the Makefile clearly has the values set and are used during ``make``. Brett, I'm building MacPython binary distributions with an LDFLAGS configure option, as in $PYTHONSRC/configure -C --enable-framework LDFLAGS=-Wl,-x This has suddenly started failing with a very mysterious error message. When the make tries to build the extension modules I get running build running build_ext usage: setup.py [options] setup.py: error: no such option: -W Could this somehow be caused by your fix? -- Jack Jansen, <[EMAIL PROTECTED]>, http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Hi all,
On 27 dec 2004, at 19:27, Chris Barker wrote:
Robin has added versioning to the latest wxPython, and I. for one am
ecstatic. It works great for me. I am generally using 2.5.3, but have
2.4.2 installed, and a number of my apps depend on it (on Linux
anyway, it's pretty useless on OS-X)
It's great to be able to put:
import wxversion
wxversion.select("2.4")
At the top of my apps, and know that they'll use the version of
wxPython I tested against.
Would it be an idea to submit a PEP for extending the 'import' keyword?
I can imagine it to be like:
import spam version 1
import foo version 2, 4
import bar version 7, 1, 6
with version numbers consisting of some fixed maximum of parts and the
version number parts not given might be wildcards.
We could then have a per module version system like:
.../
spam/
1.0.1/
... [version 1.0.1 stuff in here]
1.5.7/
... [version 1.5.7 stuff in here]
there should be nothing else in the module directory, except for a
mechanism to further support versioning.
Default behaviour of 'import spam' would be to select the most recent
version. We might want to override that by pointing to some other
version. This might be achieved using a symbolic link/alias/shortcut to
the directory of that version (spam/current -> spam/1.0.1).
More like the directory/module method would be to allow for a
__version__.py file in 'spam'. Content of this file is to be
determined, but I think it should at least something like __current__
or __version__ to act as the pointer to the current version.
--eric
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Eric Nieuwland wrote: Would it be an idea to submit a PEP for extending the 'import' keyword? No. Normally, packages should aim for backwards compatibility, so that applications would only want to specify a minimum version, such as import xml assert xml.version_info > (0,8,2) If you really want side-by-side installation of different versions, and a mechanism to select between them, the package could support import xml_0_8_2 as xml IOW, "import-as" should be sufficient for what you want to achieve. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Zipfile needs?
I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I can open a pseudo-file for STORED files in binary read mode, for example, to allow reading zip-in-zip files without fully occupying memory. -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Zipfile needs?
Scott David Daniels <[EMAIL PROTECTED]> wrote: > > I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary > motivation is that Project Gutenberg seems to be starting to use BZIP2 > compression for some of its zips. What other wish list things do > people around here have for zipfile? I thought I'd collect input here > and make a PEP. > > I can open a pseudo-file for STORED files in binary read mode, for > example, to allow reading zip-in-zip files without fully occupying > memory. I'm not sure that zipfile needs BZIP2 support...being that there is a bzip2 module. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
On Dec 27, 2004, at 8:45 PM, Chris Barker wrote: The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well. However, it's also quite new, and who know what problems will arise. For those interested, here's a synopsis. http://wiki.wxpython.org/index.cgi/MultiVersionInstalls I just cleaned up a bunch of spelling on that wiki page and rewrote the "what about py2exe" section. It now mentions py2app, is (hopefully) written more clearly, and includes an easier alternative for bundling the desired version of wxPython (wxversion can be used from setup.py). -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Zipfile needs?
On Dec 27, 2004, at 8:43 PM, Josiah Carlson wrote: Scott David Daniels <[EMAIL PROTECTED]> wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I can open a pseudo-file for STORED files in binary read mode, for example, to allow reading zip-in-zip files without fully occupying memory. I'm not sure that zipfile needs BZIP2 support...being that there is a bzip2 module. Note that the bzip2 module is named bz2 and does provide a file-like-interface. Also, it is implemented entirely as a C extension (ick). -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Martin> If you really want side-by-side installation of different Martin> versions, and a mechanism to select between them, the package Martin> could support Martin> import xml_0_8_2 as xml Martin> IOW, "import-as" should be sufficient for what you want to achieve. That's more-or-less the scheme adopted where I work. If we have two versions of a sybase module installed side-by-side, the imports might look like: import local.db.sybase.v1 as sybase or import local.db.sybase.v2 as sybase It's a bit cumbersome, but it's worked okay for us so far. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Pythonmac-SIG] The versioning question...
Martin v. Löwis wrote: No. Normally, packages should aim for backwards compatibility, so that applications would only want to specify a minimum version, such as import xml assert xml.version_info > (0,8,2) Well, yes, but life is not always so simple, and while, as a rule, version 2.3 should be backward compatible with 2.2, I see no reason to expect that version 5.0 and version 2.0 will be compatible. Frankly, backward compatibility can be a real impediment to progress. (when will "true division" be default?) If you really want side-by-side installation of different versions, and a mechanism to select between them, the package could support import xml_0_8_2 as xml IOW, "import-as" should be sufficient for what you want to achieve. This really doesn't work well for complex packages. I was quite involved with the debate about versioning for wxPython (and helped drive it happening) and that was what I originally proposed. The problem is that you have a whole pile of modules and libs and user code that all imports the package. There are a LOT of "import wx" lines in the wxPython library, and a whole bunch more in a sizable wxPython app. As you upgrade, every one of those would have to be changed to import wx_x_y_z as wx This was not considered a reasonable solution. Among other things, it's really nice to be able to make a small change in just one file, and be able to test your app against a new version. Other approaches were suggested and were used in the past: - A script that you run to change what version is installed - An environment variable that you set. - Whatever else I can't recall. Personally, I was only going to be really happy with an approach that worked at the python level, in one place. The versioning system that wxPython now has is quite nice, and seems to fit most people's needs well. However, it's also quite new, and who know what problems will arise. For those interested, here's a synopsis. http://wiki.wxpython.org/index.cgi/MultiVersionInstalls Skip Montanaro wrote: There's more to it than that: 1. Most people simply don't need it. My first brush with versioning Python modules occurred in the past few months at my current job, and that was mostly so our SWIG'd modules could be released in step with our locally written C++ libraries. I used Python for ten years before that without ever feeling the need for versioning. I'm surprised, but I think maturity and complexity has something to do with it. The more mature Python and its add-on packages become, the more this will be an issue. There was certainly a lot of uproar about backward compatible changes in Python itself, another issue that could be lessoned by a bit easier accommodation of multiple versions of python. (or why, or why did Redhat not put a version on their #! lines? have they yet?) 2. I think it will be challenging to come up with a versioning scheme that works for everyone. This is very true we had a hard enough time coming to a consensus among a small group of wxPython developers. I'm not sure we even did anyway, Robin just decided on one to implement. > To do versioning at work we had to solve issues related to module naming, directory structure, source code control and local build environment tools to make it work. Wow! that sounds a lot more complex that it has to be, but I'm sure there's a lot to what you've done. Note that you've kind of contradicted yourself (or at least contradicted Martin). I suspect your versioning issues would have been much simpler if Python itself had supported it. Write a PEP and put it out for review. I don't recall seeing this raised in the Python community before. That I'm surprised about. I've seen it (and brought it up) a number of times. I know there are a few major packages with roll your own versioning systems, wxPython, PyGTK, and PMW to mention a few. > I certainly don't think it's something the core developers worry about, This is quite true, and why I haven't bothered with a PEP, but maybe I've got the thinking backwards, we need the PEP to get the "important" people thinking about it. -Chris -- Christopher Barker, Ph.D. Oceanographer NOAA/OR&R/HAZMAT (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Re: Zipfile needs?
Josiah Carlson wrote: Scott David Daniels <[EMAIL PROTECTED]> wrote: I'm hoping to add BZIP2 compression to zipfile for 2.5. My primary motivation is that Project Gutenberg seems to be starting to use BZIP2 compression for some of its zips. What other wish list things do people around here have for zipfile? I thought I'd collect input here and make a PEP. I can open a pseudo-file for STORED files in binary read mode, for example, to allow reading zip-in-zip files without fully occupying memory. I'm not sure that zipfile needs BZIP2 support...being that there is a bzip2 module. - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python-python-dev%40m.gmane.org But if you look at the zipfile document, BZIP2 is a compression technique you can use (per file) in a zip archive. In fact, I use bz2 to compress/decompress, but the data still needs to inhabit the archive. -- -- Scott David Daniels [EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Re: [Python-checkins] python/dist/src setup.py, 1.208, 1.209
Jack Jansen wrote: On 18-dec-04, at 21:48, [EMAIL PROTECTED] wrote: Update of /cvsroot/python/python/dist/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv21493 Modified Files: setup.py Log Message: Switch from getting LDFLAGS and CPPFLAGS from the environment to the Makefile. This is to avoid a problem that inconsistently comes up where the environment variable is unset while the Makefile clearly has the values set and are used during ``make``. Brett, I'm building MacPython binary distributions with an LDFLAGS configure option, as in $PYTHONSRC/configure -C --enable-framework LDFLAGS=-Wl,-x This has suddenly started failing with a very mysterious error message. When the make tries to build the extension modules I get running build running build_ext usage: setup.py [options] setup.py: error: no such option: -W Could this somehow be caused by your fix? Yep, it's my doing. I bet optparse is raising an error since it doesn't have options for -W1 or -x registered with the parser. Anyone off the top of their head know how to cause optparse to just skip over options it doesn't know about? I am on vacation at the moment so I will deal with this when I get back this weekend. -Brett ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
