From jonathan.taylor at stanford.edu Wed Oct 1 01:25:30 2003 From: jonathan.taylor at stanford.edu (Jonathan Taylor) Date: Wed Oct 1 01:30:20 2003 Subject: [Distutils] errors building with mingw32 Message-ID: <000801c387dc$6f405db0$95b742ab@STANFORDCH0QZD> Hi, I have a possibly stupid question -- my apologies. I am trying to build some modules written on a Linux platform in Windows (Windows 2000) using mingw32. I have tried building the following REALLY basic module and am getting some strange errors (it works fine with VC++ 6.0). My command line is python setup.py build -c mingw32 Module: #include static PyObject *myfoo(PyObject *self, PyObject *args, PyObject *keywords); /* Module methods */ static PyMethodDef FooMethods[] = { {"_myfoo", (PyCFunction) myfoo, METH_VARARGS|METH_KEYWORDS, "FOO!"}, {NULL, NULL, 0, NULL} /* Sentinel */ }; /* Initialize the module foo */ void initfoo(void) { PyObject *module; module = Py_InitModule("foo", FooMethods); } static PyObject *myfoo(PyObject *self, PyObject *args, PyObject *keywords) { int output_int; char *keyword_list[] = {"output_int", NULL}; if (! PyArg_ParseTupleAndKeywords(args, keywords, "i", keyword_list, &output_int)) { PyErr_SetObject(PyExc_TypeError, Py_BuildValue("OO", args, keywords)); return NULL; } fprintf(stderr,"%d\n", output_int); return(Py_None); } Here is my setup.py file from distutils.core import setup, Extension import os libraries=[] library_dirs=[] include_dirs=[] mincutils_mod = [] mincutils_mod.append(Extension('foo', sources = ['foo.c'], include_dirs=include_dirs, library_dirs=library_dirs, libraries=libraries)) setup (name = 'foo', version = '0.4', description = 'This is a package to foo.', author = 'Jonathan E. Taylor', author_email = 'jonathan.taylor@stanford.edu', url = '', long_description = ''' ''', ext_modules = mincutils_mod) and the error messages: F:\Python Example>python setup.py build -c mingw32 running build running build_ext building 'foo' extension writing build\temp.win32-2.3\Release\foo.def F:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.3\Release\foo.o b uild\temp.win32-2.3\Release\foo.def -LF:\Python23\libs -LF:\Python23\PCBuild -lp ython23 -o build\lib.win32-2.3\foo.pyd build\temp.win32-2.3\Release\foo.o(.text+0x94):foo.c: undefined reference to `_i mp__PyExc_TypeError' build\temp.win32-2.3\Release\foo.o(.text+0xc1):foo.c: undefined reference to `_i mp___Py_NoneStruct' error: command 'gcc' failed with exit status 1 Any help would be greatly appreciated. Thanks, Jonathan Taylor -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20030930/95a85323/attachment.html From Paul.Moore at atosorigin.com Wed Oct 1 04:15:01 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Wed Oct 1 04:15:47 2003 Subject: [Distutils] errors building with mingw32 Message-ID: <16E1010E4581B049ABC51D4975CEDB8802C097E7@UKDCX001.uk.int.atosorigin.com> From: Jonathan Taylor [mailto:jonathan.taylor@stanford.edu] > and the error messages: > F:\Python Example>python setup.py build -c mingw32 > running build > running build_ext > building 'foo' extension > writing build\temp.win32-2.3\Release\foo.def > F:\MinGW\bin\gcc.exe -mno-cygwin -shared -s build\temp.win32-2.3\Release\foo.o b > uild\temp.win32-2.3\Release\foo.def -LF:\Python23\libs -LF:\Python23\PCBuild -lp > ython23 -o build\lib.win32-2.3\foo.pyd > build\temp.win32-2.3\Release\foo.o(.text+0x94):foo.c: undefined reference to `_i > mp__PyExc_TypeError' > build\temp.win32-2.3\Release\foo.o(.text+0xc1):foo.c: undefined reference to `_i > mp___Py_NoneStruct' > error: command 'gcc' failed with exit status 1 > > Any help would be greatly appreciated. You need to build a libpython23.a library (it's not supplied with Python). See section 6.2.2 of "Installing Python Modules" in the Python documentation, it gives all the steps you need. Hope this helps, Paul. From amk at amk.ca Wed Oct 1 10:05:08 2003 From: amk at amk.ca (amk@amk.ca) Date: Wed Oct 1 10:05:15 2003 Subject: [Distutils] newbie distutils questions *please*... In-Reply-To: <20030930235025.GA9930@spawar.navy.mil> References: <20030930235025.GA9930@spawar.navy.mil> Message-ID: <20031001140508.GB24506@rogue.amk.ca> On Tue, Sep 30, 2003 at 04:50:25PM -0700, seberino@spawar.navy.mil wrote: > 3. Will bdist_rpm install JUST pyc files (bytecode)??? > Will sdist install JUST py (source) files??? > What about installing source and bytecode?? (py and pyc)?? > How do that and is THAT a good idea??? Binary distributions (bdist) means that C extensions are compiled and the user installing them doesn't need a C compiler. .py files are also installed, and may or may not be compiled into .pyc files, depending on the bdist format. Source distributions require users to run "setup.py install" to install them, and if the package contains C extensions and the user doesn't have a C compiler, they'll be unable to install the package. For packages consisting of only Python code, there's only a slight difference between source and binary distributions from the end user's point of view. C extensions make the difference greater; in particular, few Windows users will have a compiler. --amk From amk at amk.ca Wed Oct 1 10:05:33 2003 From: amk at amk.ca (amk@amk.ca) Date: Wed Oct 1 10:05:42 2003 Subject: [Distutils] "maintainer" definition In-Reply-To: <20030930123841.GA1583@mawhrin.net> References: <20030929181736.GA29441@mawhrin.net> <20030930120343.GA19041@rogue.amk.ca> <20030930123841.GA1583@mawhrin.net> Message-ID: <20031001140533.GC24506@rogue.amk.ca> On Tue, Sep 30, 2003 at 01:38:41PM +0100, Mikhail Sobolev wrote: > So in case the original author still works on this piece of software, > the maintainer field won't be filled? Correct. > Do I understand right that at the moment both author and maintainer are > "single entity" parameters? The case when there are several Also correct. --amk From slash at dotnetslash.net Wed Oct 1 17:31:49 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed Oct 1 18:04:28 2003 Subject: [Distutils] "maintainer" definition In-Reply-To: <20031001140533.GC24506@rogue.amk.ca> Message-ID: On Wed, 1 Oct 2003 amk@amk.ca wrote: > On Tue, Sep 30, 2003 at 01:38:41PM +0100, Mikhail Sobolev wrote: > > So in case the original author still works on this piece of software, > > the maintainer field won't be filled? > > Correct. Wouldn't it be better to have the author and the maintainer fields be the same if the author is still working on it? I would interpret a blank maintainer field to be "unmaintained". mwa -- Mark W. Alexander slash@dotnetslash.net From seberino at spawar.navy.mil Thu Oct 2 20:38:52 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Thu Oct 2 20:38:58 2003 Subject: [Distutils] newbie distutils questions *please*... In-Reply-To: <20031001140508.GB24506@rogue.amk.ca> References: <20030930235025.GA9930@spawar.navy.mil> <20031001140508.GB24506@rogue.amk.ca> Message-ID: <20031003003852.GA17438@spawar.navy.mil> Thanks! This is all great and useful info. sdist = py files bdist* = py or pyc files *Which* bdist_* switches have py files and which have pyc files?? Especially what do bdist_rpm and bdist have? Chris On Wed, Oct 01, 2003 at 10:05:08AM -0400, amk@amk.ca wrote: > On Tue, Sep 30, 2003 at 04:50:25PM -0700, seberino@spawar.navy.mil wrote: > > 3. Will bdist_rpm install JUST pyc files (bytecode)??? > > Will sdist install JUST py (source) files??? > > What about installing source and bytecode?? (py and pyc)?? > > How do that and is THAT a good idea??? > > Binary distributions (bdist) means that C extensions are compiled and the > user installing them doesn't need a C compiler. .py files are also > installed, and may or may not be compiled into .pyc files, depending on the > bdist format. > > Source distributions require users to run "setup.py install" to install > them, and if the package contains C extensions and the user doesn't have a C > compiler, they'll be unable to install the package. > > For packages consisting of only Python code, there's only a slight > difference between source and binary distributions from the end user's point > of view. C extensions make the difference greater; in particular, few > Windows users will have a compiler. > > --amk > > _______________________________________________ > Distutils-SIG maillist - Distutils-SIG@python.org > http://mail.python.org/mailman/listinfo/distutils-sig -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From seberino at spawar.navy.mil Thu Oct 2 20:39:12 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Thu Oct 2 20:39:16 2003 Subject: [Distutils] newbie distutils questions *please*... In-Reply-To: <1064976570.2750.13.camel@localhost.localdomain> References: <20030930235025.GA9930@spawar.navy.mil> <1064976570.2750.13.camel@localhost.localdomain> Message-ID: <20031003003912.GB17438@spawar.navy.mil> Jeremy Thanks. I needed that. CS On Tue, Sep 30, 2003 at 10:49:30PM -0400, Jeremy Hylton wrote: > On Tue, 2003-09-30 at 19:50, seberino@spawar.navy.mil wrote: > > 1. What goes into __init__.py files??? I know what setup.py contents are > > but I don't recall seeing advice on what to put in __init__.py. > > You don't need to put anything into __init__.py files. They are > necessary to make Python recognize a directory as a package, but they > can be empty. > > If you put code in __init__.py, it is executed when the package is > imported, including the first time a submodule of a package is > imported. It is sometimes useful to execute code here, but that's up to > you. > > > 2. I have a ton of data files to list in setup(...) with the > > data_files switch. Can I avoid listing EVERY file somehow??? > > Can I use a wildcard in the filename???? > > It can be tedious to list all the data files. The setup.py script is a > regular Python script, though, so you can compute the full list from the > wildcard. The glob module might do what you want or you can search for > files using os.path.walk. > > > 3. Will bdist_rpm install JUST pyc files (bytecode)??? > > Will sdist install JUST py (source) files??? > > What about installing source and bytecode?? (py and pyc)?? > > How do that and is THAT a good idea??? > > The bdist and sdist commands do not install anything. They generate > distributions that can be used to install software. You probably know > that, but I want to make sure we're on the same page. > > An sdist distribution contains only .py files. The source distribution > could work with many versions of Python, but .pyc files are tied to a > particular version. The source distribution generates .pyc files when a > user unpacks it and runs "python setup.py install". > > I believe a bdist command will have the same effect. I'm not sure about > bdist_rpm, but bdist_wininst only puts source files in the distribution. > > > 4. If I tell setup(...) I have a package somewhere with > > packages = ["..."] > > does that mean it will get ALL files in that directory without > > me having to specify them individually?? > > It means all .py files. It will ignore any other file in the directory. > Note that you have to explicitly include subpackages in the list. > > > What if I want to OMIT a file like the CVS directory?!?! > > It gets skipped, because it isn't listed as a package. If you tried to > list it as a package, it still wouldn't contain any .py files. > > Note that it is a little tedious to get non-Python files installed with > a package. If you want a data file to be included next to the .py file, > you've got to go to a lot of trouble. > > Jeremy > -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From jlbec at evilplan.org Thu Oct 2 21:19:53 2003 From: jlbec at evilplan.org (Joel Becker) Date: Thu Oct 2 21:19:56 2003 Subject: [Distutils] Variable substitution Message-ID: <20031003011952.GI21486@parcelfarce.linux.theplanet.co.uk> Folks, A quick look at the distutils source, some extensive googling, and even walking a few months of the distutils-sig archive all have yet to yield an answer to my quandry. I'm looking to substitute some variables at 'build' time ala what autoconf/configure does to .in files. I have some configuration I want to set up with my setup.py script and insert into a file (specifically, the location of some support files). I can't find a way to do this in distutils. My first thought was to do the work by hand before calling distutils.core.setup(), but then I realized that I'd have no idea what setup() thought certain values would be (eg, prefix) until after I'd called it. Is there a recommended way to accomplish this? Is there a way I can add this? A quick pointer would help. Joel -- "In the long run...we'll all be dead." -Unknown http://www.jlbec.org/ jlbec@evilplan.org From seefeld at sympatico.ca Fri Oct 3 08:57:20 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri Oct 3 08:53:53 2003 Subject: [Distutils] Variable substitution References: <20031003011952.GI21486@parcelfarce.linux.theplanet.co.uk> Message-ID: Joel Becker wrote: > Folks, > A quick look at the distutils source, some extensive googling, > and even walking a few months of the distutils-sig archive all have yet > to yield an answer to my quandry. I'm looking to substitute some > variables at 'build' time ala what autoconf/configure does to .in files. > I have some configuration I want to set up with my setup.py script and > insert into a file (specifically, the location of some support files). > I can't find a way to do this in distutils. My first thought > was to do the work by hand before calling distutils.core.setup(), but > then I realized that I'd have no idea what setup() thought certain > values would be (eg, prefix) until after I'd called it. > Is there a recommended way to accomplish this? Is there a way I > can add this? A quick pointer would help. hey Joel, I had the exact same question some months ago. Indeed, there doesn't seem to be a way to do this with existing distutils features. What I did was to provide my own installation command that does the value replacement on the fly when copying files to their final destination. Just for the record: even that might not be enough if, as is the case with the windows installer generated by 'bdist_wininst', the prefix is only known when you invoke the installer, not when you call python setup.py install. I'd really like distutils to provide better support for this kind of thing. It doesn't seem that uncommon to have 'datafiles' that have to be referenced from inside the code. Hope that gets you started, Stefan From andrey at freemail.lt Tue Oct 7 17:16:46 2003 From: andrey at freemail.lt (Andrey Lebedev) Date: Tue Oct 7 17:20:17 2003 Subject: [Distutils] Re: Variable substitution References: <20031003011952.GI21486@parcelfarce.linux.theplanet.co.uk> Message-ID: On Fri, 03 Oct 2003 08:57:20 -0400, Stefan Seefeld wrote: > Joel Becker wrote: > I'd really like distutils to provide better support for this kind > of thing. It doesn't seem that uncommon to have 'datafiles' that > have to be referenced from inside the code. I'm just facing this problem for my project. User has installed it from source distribution to custom prefix (python setup.py install --prefix /usr/local/kedpm-0.2.5) and program can't find its data files now. After reading this list it seems there is no common way to inform program at runtime where is it installed. I'm looking for possibility to generate some sort of configuration module on build time, e.g prefix.py:: prefix = '/usr/lib/kedpm-0.2.5' exec-prefix = '/usr/lib/kedpm-0.2.5' ... and importing it in application to adjust data files' locations. Is anybody thought about such approach? Is there any known or possible pitfalls with it? Thanks -- Andrey Lebedev aka -.- . -.. -.. . .-. Software engineer Homepage: http://micro.lt/~andrey/ Jabber ID: kedder@jabber.ru From seefeld at sympatico.ca Tue Oct 7 17:29:35 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Tue Oct 7 17:25:06 2003 Subject: [Distutils] Re: Variable substitution References: <20031003011952.GI21486@parcelfarce.linux.theplanet.co.uk> Message-ID: <4ab87b2cf47f789eb487e8e43e8c400e3f832c3d@Orthosoft.ca> Andrey Lebedev wrote: > Is anybody thought about such approach? I used two approaches: Modify the executable at install time, inserting the prefix that was used via 'python setup.py install --prefix=...' The problem with this approach is that it fails to take into account for example wininst, where the real path is only known after executing the windows installer. The other solution I used is to assume a common prefix for executables and datafiles (i.e. /bin or /scripts for the executable, /share for the data files), and then computing the datadir from sys.argv[0]. The problem with this is that not all installations use a common prefix for executables and data files. Hope this helps, Stefan From seberino at spawar.navy.mil Tue Oct 7 18:00:23 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Tue Oct 7 18:00:29 2003 Subject: [Distutils] Why data_files listed in setup.py being ignored?! How fix? Message-ID: <20031007220023.GA10834@spawar.navy.mil> My setup.py basically looks something like this..... import glob ... setup( ..., ..., data_files = [ ( "pixmaps", glob.glob("pixmaps/*.xpm") ) ] .... ) The package I made with "python setup.py sdist" looks good except none of the data_files show up in tarball?!?! How fix? Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From joonas.paalasmaa at iki.fi Wed Oct 8 05:28:59 2003 From: joonas.paalasmaa at iki.fi (Joonas Paalasmaa) Date: Wed Oct 8 05:29:04 2003 Subject: [Distutils] Typo in "Distributing Python Modules: 3.3.3" Message-ID: <20031008092859.2505.qmail@cyclone.neutech.fi> Hello, In section "3.3.3 Preprocessor options" of Distributing Python Modules it reads: Extension(..., define_macros=[('NDEBUG', '1')], ('HAVE_STRFTIME', None), undef_macros=['HAVE_FOO', 'HAVE_BAR']) Shouldn't it be instead: Extension(..., define_macros=[('NDEBUG', '1'), ('HAVE_STRFTIME', None)], undef_macros=['HAVE_FOO', 'HAVE_BAR']) From theller at python.net Wed Oct 8 06:03:39 2003 From: theller at python.net (Thomas Heller) Date: Wed Oct 8 08:04:10 2003 Subject: [Distutils] Typo in "Distributing Python Modules: 3.3.3" In-Reply-To: <20031008092859.2505.qmail@cyclone.neutech.fi> (Joonas Paalasmaa's message of "Wed, 08 Oct 2003 09:28:59 GMT") References: <20031008092859.2505.qmail@cyclone.neutech.fi> Message-ID: <7k3gujus.fsf@python.net> Joonas Paalasmaa writes: > Hello, > > In section "3.3.3 Preprocessor options" of Distributing Python Modules > it reads: Extension(..., > define_macros=[('NDEBUG', '1')], > ('HAVE_STRFTIME', None), > undef_macros=['HAVE_FOO', 'HAVE_BAR']) Shouldn't it be > instead: Extension(..., > define_macros=[('NDEBUG', '1'), > ('HAVE_STRFTIME', None)], > undef_macros=['HAVE_FOO', 'HAVE_BAR']) Right. In general, it is better to create a patch on SF for these things, but it is not needed for this one anymore, I fixed it. Thanks, Thomas From seberino at spawar.navy.mil Wed Oct 8 17:00:26 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Wed Oct 8 17:00:30 2003 Subject: [Distutils] Can't get ANY data files included!!! Please help! Message-ID: <20031008210026.GA19816@spawar.navy.mil> I added an include line in MANIFEST.in but still cannot get *any* data files included!! I made a toy example to show my problem... ============================================= Here are my package files: ============================================= setup.py MANIFEST.in foo.py somedata ============================================= Here is contents of setup.py: ============================================= from distutils.core import setup setup(name = "foo", version = "1.0", data_files = [ ("data", ["somedata"]) ], packages = [""]) ============================================= Here is MANIFEST.in: ============================================= include "somedata" ============================================= ============================================= Here is what happens when I try to do "python setup.py sdist": ============================================= % python setup.py sdist running sdist ...etc. reading manifest template 'MANIFEST.in' warning: no files found matching '"somedata"' ...etc. ============================================= I tried *absolute* paths in MANIFEST.in and data_files. I tried to move data files to different places. I tried using wild cards. NOTHING seems to make distutils SEE my data files?!?!? Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From seberino at spawar.navy.mil Wed Oct 8 19:06:16 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Wed Oct 8 19:07:37 2003 Subject: [Distutils] when install, says header (.h) file is an unknown file type!?!?! How fix? Message-ID: <20031008230616.GA20158@spawar.navy.mil> I have a program that has Python and C code. I added Extension stuff to setup.py and all .c and .h files get into tarball fine. When I try to INSTALL the package it says header (.h) file is an unknown type. How fix this??? Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From amk at amk.ca Wed Oct 8 20:32:03 2003 From: amk at amk.ca (A.M. Kuchling) Date: Wed Oct 8 20:33:30 2003 Subject: [Distutils] Call for Distutils 2.0 suggestions Message-ID: <01145436-F9F0-11D7-8A77-000A956F1D08@amk.ca> Greg Ward did a really good job designing and putting together the Distutils, but the intervening years have exposed some shortcomings in it, and it's probably time to fix them. I've created a wiki page for Distutils 2.0 ideas at: http://www.python.org/cgi-bin/moinmoin/DistUtils20> Please go edit the page and add any bugs or shortcomings you've noticed. --amk From seefeld at sympatico.ca Wed Oct 8 21:55:38 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Wed Oct 8 21:58:14 2003 Subject: [Distutils] Call for Distutils 2.0 suggestions In-Reply-To: <01145436-F9F0-11D7-8A77-000A956F1D08@amk.ca> References: <01145436-F9F0-11D7-8A77-000A956F1D08@amk.ca> Message-ID: <3F84C01A.30500@sympatico.ca> A.M. Kuchling wrote: > Greg Ward did a really good job designing and putting together the > Distutils, but the intervening years have exposed some shortcomings in > it, and it's probably time to fix them. I've created a wiki page for > Distutils 2.0 ideas at: > http://www.python.org/cgi-bin/moinmoin/DistUtils20> > > Please go edit the page and add any bugs or shortcomings you've noticed. done. Great to hear that you plan to work on distutils. Do you have any timeframe in mind ? What kind of changes are you considering ? Just (minor) fixes or even changes to the underlying design ? I'v seen a lot of projects extending distutils considerably, it may be interesting to carefully look into their code and try to use their experience. I'm thinking of projects such as 4suite, for example... I'm particularly interested into bridging autoconf/make based build systems with distutils, and would like to collaborate on that. I'm working on projects where I wrap existing projects (originally C/C++ libraries) so the integration should be as little intrusive as possible. Also, you may communicate with the boost.python developers. Having a simple way to build boost.python extensions would be extremely useful... Regards, Stefan From nieder at mail.ru Wed Oct 8 19:21:55 2003 From: nieder at mail.ru (Ricardo Niederberger Cabral) Date: Wed Oct 8 22:12:32 2003 Subject: [Distutils] Can't get ANY data files included!!! Please help! In-Reply-To: <20031008210026.GA19816@spawar.navy.mil> References: <20031008210026.GA19816@spawar.navy.mil> Message-ID: <20031008232155.GA4626@localhost> * seberino@spawar.navy.mil [2003-10-08 18:12]: > setup(name = "foo", > version = "1.0", > data_files = [ ("data", ["somedata"]) ], > packages = [""]) [...] > I tried *absolute* paths in MANIFEST.in and data_files. > I tried to move data files to different places. I tried using wild cards. > > NOTHING seems to make distutils SEE my data files?!?!? I guess you should list files and not dirs. Are you sure "somedata" is a file ? What i've done before to include everything inside a datadir is: data_files = [("share/MyApp",map(lambda x: 'MyAppData/'+x, os.listdir("MyAppData")))], # include all MyAppData/ content You could also use "['MyAppData/'+x for x in os.listdir("MyAppData")]" there instead of that map call. Best regards, -- rnc From seberino at spawar.navy.mil Thu Oct 9 19:00:49 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Thu Oct 9 19:00:53 2003 Subject: [Distutils] How handle header files? Message-ID: <20031009230049.GA23725@spawar.navy.mil> I know how to configure C code with Extension class in setup.py. But, how do you handle header files??.. Do you mention them in your Extension(...) line?? It seems you must 1. Treat them like data files and put them *somewhere*. 2. Now you must add -I command to compilation of .c files that points there. An example of this or pointers would be VERY nice. Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From amk at amk.ca Fri Oct 10 08:09:49 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 10 08:09:56 2003 Subject: [Distutils] Call for Distutils 2.0 suggestions In-Reply-To: <3F84C01A.30500@sympatico.ca> References: <01145436-F9F0-11D7-8A77-000A956F1D08@amk.ca> <3F84C01A.30500@sympatico.ca> Message-ID: <20031010120949.GA5240@rogue.amk.ca> On Wed, Oct 08, 2003 at 09:55:38PM -0400, Stefan Seefeld wrote: > Great to hear that you plan to work on distutils. Do you have any > timeframe in mind ? What kind of changes are you considering ? > Just (minor) fixes or even changes to the underlying design ? Timeframe: for Python 2.4. The Pythonmac-SIG is moving on building a package manager, and that's likely to drive some changes. Changes: mostly just cleaning up and rearrangements; I don't want to do a massive set of changes that would break existing scripts or require creating a distutils2 package. --amk From seefeld at sympatico.ca Fri Oct 10 10:14:47 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Fri Oct 10 10:09:48 2003 Subject: [Distutils] Call for Distutils 2.0 suggestions References: <01145436-F9F0-11D7-8A77-000A956F1D08@amk.ca> <3F84C01A.30500@sympatico.ca> <20031010120949.GA5240@rogue.amk.ca> Message-ID: amk@amk.ca wrote: > On Wed, Oct 08, 2003 at 09:55:38PM -0400, Stefan Seefeld wrote: > >>Great to hear that you plan to work on distutils. Do you have any >>timeframe in mind ? What kind of changes are you considering ? >>Just (minor) fixes or even changes to the underlying design ? > > > Timeframe: for Python 2.4. The Pythonmac-SIG is moving on building a > package manager, and that's likely to drive some changes. > > Changes: mostly just cleaning up and rearrangements; I don't want to do a > massive set of changes that would break existing scripts or require creating > a distutils2 package. I fully agree that backward compatibility is important. But I do think that distutils in its current state is not very useful for slightly non-trivial projects (specifically those involving C/C++ extensions), and, while making it useful by filling some holes is not that hard, it's certainly quite a bit more than just 'cleanup' and 'rearrangement'. How would you plan to do the work ? Are you interested in people collaborating ? Will the development / discussion happen on this list ? Regards, Stefan From seberino at spawar.navy.mil Sat Oct 11 03:02:58 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Sat Oct 11 03:03:02 2003 Subject: [Distutils] newbie questions about installing files to desired directories... Message-ID: <20031011070258.GA6133@spawar.navy.mil> Please help with newbie problems installing files into right directories. My source code is in $HOME/hitv2/src directory. In $HOME/hitv2/setup.py I tried package = ["src"] and package_dir = {"" : "src"} at various times. Q1: How can I get files in src to be installed into /usr/lib/python2.2/site-packages/hitv2 instead of /usr/lib/python2.2/site-packages/src or /usr/src ??? Q2: In setup.py I have something like this: data_files = [ ("???/data", ["data/*"]) ] What should "???" be equal to if I want these data files to go into /usr/lib/python2.2/site-packages/hitv2/data ??? (If "???/data" = "data" then files go into /usr/data!!?!?) Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From kevin_cazabon at hotmail.com Wed Oct 15 02:41:32 2003 From: kevin_cazabon at hotmail.com (Kevin_Cazabon@hotmail.com) Date: Wed Oct 15 03:38:13 2003 Subject: [Distutils] py2exe problems with win32ui Message-ID: I have an application that uses win32ui that I've built with py2exe. It runs perfectly on Windows 2000/XP, but the import of win32ui fails on Windows 98SE (even with force-import of win32ui in the setup.cfg). Strange thing is that I can run the pure python version just fine on Windows 98. Copying the "local" version of win32ui.pyd from a normal Python install on Win98 doesn't help either. ANy suggestions? Thanks! Kevin Cazabon. From theller at python.net Wed Oct 15 15:25:39 2003 From: theller at python.net (Thomas Heller) Date: Wed Oct 15 15:26:12 2003 Subject: [Distutils] py2exe problems with win32ui In-Reply-To: (Kevin's message of "Wed, 15 Oct 2003 00:41:32 -0600") References: Message-ID: "Kevin_Cazabon@hotmail.com" writes: > I have an application that uses win32ui that I've built with py2exe. It > runs perfectly on Windows 2000/XP, but the import of win32ui fails on > Windows 98SE (even with force-import of win32ui in the setup.cfg). > > Strange thing is that I can run the pure python version just fine on Windows > 98. Copying the "local" version of win32ui.pyd from a normal Python install > on Win98 doesn't help either. > > ANy suggestions? If you can strip this down to a minimal example which demonstrates this problem I would be interested to look into this. You must of course also mention the py2exe, Python, and win32all version numbers. BTW: Please send further post about py2exe to comp.lang.python, distutils isn't the correct forum. Thanks, Thomas From slash at dotnetslash.net Mon Oct 20 18:11:22 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Mon Oct 20 18:11:27 2003 Subject: [Distutils] PEP 242 & Distutils2 Message-ID: There's some issues with the PEP 242 metadata and the Distutils2 Wiki discussion on REQUIRES and PROVIDES. Here's some thoughts, in the hope that we can get these in sync. First, I think it's very important to provide for a single source package to produce multiple binary packages. Marc's Egenix package is the example that comes to mind, but I also have some internal packages with the same requirement. He's obviously jumped through a lot of loops. Requiring extending 12 Distutils classes with 1600+ lines of code and mix-ins is not exactly going to entice people to provide Distutils setup scripts for their more complex projects. The REQUIRES and PROVIDES metadata information is more properly associated with binary packages than with source packages, and by extension, looking through PEP 242 each of those items apply to binary packages as well. What I'd like to see in Distutils2 is a way to map package namespaces to binary package targets. he highest level namespace would be like Marc's mxBase package, or -common in the .deb and .rpm worlds. A syntax needs to be provided to specify what binary package lower level namespaces go into. Each binary package needs it's own set of Metadata. Fields that are not specifically provided for a binary package would be inherited from the global defaults; that of the source package. Again, using Egenix as an example, mxDatetime's version is 2.0.3, mxTextTools is 2.1.0, and mxBase is 2.0.4, etc. Any subpackage that does not provide it's own version would inherit the source package's version. This works especially well for non-binary dependent information such as Author, home-page, email, etc. By definition each binary package would be required to have it's own name. This provides for REQUIRES and PROVIDES to be specified at the binary package level, which is where it makes the most sense from an end user/sysadmin/installer level. There's a monkey-wrench, however: Solaris. Solaris (SysV pkgtool*) packages are restricted to a maximum of 9 characters. So for Solaris users, the whole REQUIRES/PROVIDES mechanism falls apart because you can't reference dependencies>9 characters. So in order to support equivalent functionality on Solaris, PEP 242 needs to be extended to include an official "abbreviated-name" that is <= 9 characters. (Or worse, if there's another package tool out there with a smaller name requirement then that would be the maximum abbreviated length. As a sidebar, I assume the catalog will enforce unique names. Without unique names, REQUIRES and PROVIDES are worthless. REQUIRES=X, where there is more than one package X is less than helpful. The catalog would also have to enforce uniqueness on the abbreviated name. Whether names are acquired first-come, first-served or a registration process is required I leave to the catalog people, but it needs to be enforced somehow. mwa *Yes, I _do_ have a bdist_pkgtool (and one for HP) and I'm _trying_ to get permission to contribute them... -- Mark W. Alexander slash@dotnetslash.net From seberino at spawar.navy.mil Tue Oct 21 16:22:08 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Tue Oct 21 16:22:12 2003 Subject: [Distutils] problem with relative paths for install_purelib switch Message-ID: <20031021202208.GA15365@spawar.navy.mil> I set prefix, and install-purelib in setup.cfg. I MUST have an absolute path for install-purelib or else those files don't get installed. I thought install-purelib path could be relative to prefix value?!?!? Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From slash at dotnetslash.net Tue Oct 21 17:39:46 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Tue Oct 21 17:39:51 2003 Subject: [Distutils] Timeframe of 2.0 again? Message-ID: What was the time frame for Distutils2 again? I recall it being mentioned as "Python 2.4", been when is _that_ targeted. (I'm trying to expedite being able to sign a contributor agreement in time to get bdist_pkgtool and bdist_sdux submitted before the next ice age...) mwa -- Mark W. Alexander slash@dotnetslash.net From seberino at spawar.navy.mil Tue Oct 21 18:37:07 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Tue Oct 21 18:37:10 2003 Subject: [Distutils] How suppress warning message? (about nonstandard install path) Message-ID: <20031021223707.GA15686@spawar.navy.mil> I reset prefix to something else and happily installed everything fine. There is a warning message at end of installation about path not being in sys.path. Can I remove this warning somehow?? Chris -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From theller at python.net Wed Oct 22 03:25:54 2003 From: theller at python.net (Thomas Heller) Date: Wed Oct 22 03:26:15 2003 Subject: [Distutils] How suppress warning message? (about nonstandard install path) In-Reply-To: <20031021223707.GA15686@spawar.navy.mil> (seberino@spawar.navy.mil's message of "Tue, 21 Oct 2003 15:37:07 -0700") References: <20031021223707.GA15686@spawar.navy.mil> Message-ID: seberino@spawar.navy.mil writes: > I reset prefix to something else and happily installed > everything fine. There is a warning message at end of > installation about path not being in sys.path. > > Can I remove this warning somehow?? Insert your installation path into sys.path before running install, and remove it again after the install is finished. bdist_wininst.py does this, near line 128. Thomas From amk at amk.ca Wed Oct 22 09:35:35 2003 From: amk at amk.ca (amk@amk.ca) Date: Wed Oct 22 09:35:49 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: References: Message-ID: <20031022133535.GA1837@rogue.amk.ca> On Tue, Oct 21, 2003 at 05:39:46PM -0400, Mark W. Alexander wrote: > What was the time frame for Distutils2 again? I recall it being > mentioned as "Python 2.4", been when is _that_ targeted. There's no firm date; the vague idea is that Python 2.4 will wrap up whatever's in the CVS tree in late 2004. --amk From slash at dotnetslash.net Wed Oct 22 09:42:10 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Wed Oct 22 09:42:40 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <20031022133535.GA1837@rogue.amk.ca> References: <20031022133535.GA1837@rogue.amk.ca> Message-ID: > On Tue, Oct 21, 2003 at 05:39:46PM -0400, Mark W. Alexander wrote: > > What was the time frame for Distutils2 again? I recall it being > > mentioned as "Python 2.4", been when is _that_ targeted. > > There's no firm date; the vague idea is that Python 2.4 will wrap up > whatever's in the CVS tree in late 2004. Ok. Don't tell my employer then. That's not enough pressure ;) Also, what tools do people recommended for editing the documentation. I've poked around in 'vi' and it ain't gonna compensate for my docbook ignorance... mwa -- Mark W. Alexander slash@dotnetslash.net From anthony at interlink.com.au Wed Oct 22 09:39:23 2003 From: anthony at interlink.com.au (Anthony Baxter) Date: Wed Oct 22 09:48:58 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <20031022133535.GA1837@rogue.amk.ca> Message-ID: <200310221339.h9MDdNQQ025412@localhost.localdomain> Now that we're on the 2.4 track, is it ok for me to start updating the distutils innards to use some of the more modern python features and standard library? If so, what minimum version of python should I code for? I figure either Py2.1 or Py2.3 - I see no reason to stop at 2.2 - 2.3 is really just 2.2 with additional bugfixes &c. Anthony -- Anthony Baxter It's never too late to have a happy childhood. From mwh at python.net Wed Oct 22 10:32:07 2003 From: mwh at python.net (Michael Hudson) Date: Wed Oct 22 10:32:10 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: (Mark W. Alexander's message of "Wed, 22 Oct 2003 09:42:10 -0400 (EDT)") References: <20031022133535.GA1837@rogue.amk.ca> Message-ID: <2md6cpny1k.fsf@starship.python.net> "Mark W. Alexander" writes: >> On Tue, Oct 21, 2003 at 05:39:46PM -0400, Mark W. Alexander wrote: >> > What was the time frame for Distutils2 again? I recall it being >> > mentioned as "Python 2.4", been when is _that_ targeted. >> >> There's no firm date; the vague idea is that Python 2.4 will wrap up >> whatever's in the CVS tree in late 2004. > > Ok. Don't tell my employer then. That's not enough pressure ;) > > Also, what tools do people recommended for editing the documentation. > I've poked around in 'vi' and it ain't gonna compensate for my docbook > ignorance... Docbook? What's that? :-) I think most people use Emacs for editing the (latex) documentation. Cheers, mwh -- Premature optimization is the root of all evil. -- Donald E. Knuth, Structured Programming with goto Statements From fdrake at acm.org Wed Oct 22 10:49:32 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Wed Oct 22 10:49:42 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: References: <20031022133535.GA1837@rogue.amk.ca> Message-ID: <16278.39164.482290.543343@grendel.zope.com> Mark W. Alexander writes: > Also, what tools do people recommended for editing the documentation. > I've poked around in 'vi' and it ain't gonna compensate for my docbook > ignorance... The documentation is written in LaTeX using a large collection of custom markup. The markup is documented in "Documenting Python": http://www.python.org/doc/current/doc/doc.html As far as editing goes, I usually use XEmacs, but any text editor should do nicely. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From seberino at spawar.navy.mil Thu Oct 23 11:45:39 2003 From: seberino at spawar.navy.mil (seberino@spawar.navy.mil) Date: Thu Oct 23 11:45:48 2003 Subject: [Distutils] How suppress warning message? (about nonstandard install path) In-Reply-To: References: <20031021223707.GA15686@spawar.navy.mil> Message-ID: <20031023154539.GA22013@spawar.navy.mil> That worked. Thanks. Clean and simple solution! CS On Wed, Oct 22, 2003 at 09:25:54AM +0200, Thomas Heller wrote: > seberino@spawar.navy.mil writes: > > > I reset prefix to something else and happily installed > > everything fine. There is a warning message at end of > > installation about path not being in sys.path. > > > > Can I remove this warning somehow?? > > Insert your installation path into sys.path before running install, > and remove it again after the install is finished. > bdist_wininst.py does this, near line 128. > > Thomas > -- _______________________________________ Christian Seberino, Ph.D. SPAWAR Systems Center San Diego Code 2872 49258 Mills Street, Room 158 San Diego, CA 92152-5385 U.S.A. Phone: (619) 553-9973 Fax : (619) 553-6521 Email: seberino@spawar.navy.mil _______________________________________ From gfa2c at gmx.net Fri Oct 24 06:29:29 2003 From: gfa2c at gmx.net (gfa2c) Date: Fri Oct 24 06:30:41 2003 Subject: [Distutils] chicken and egg? Message-ID: <3F98FF09.A87E7AFA@gmx.net> Hello distutils-sig, I cannot install a Python application because it needs distutils. When I try to install distutils with its setup.py, it ends in error because something is missing. I had a look at the doumentation online and I still don't know how to proceed. Can you provide a *specific* link? Also is there a tar.gz for the documentation with text or html format? Thanks! -- gianfranco accardo gfa2c gmx.net @ From amk at amk.ca Fri Oct 24 07:47:16 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 24 07:47:20 2003 Subject: [Distutils] chicken and egg? In-Reply-To: <3F98FF09.A87E7AFA@gmx.net> References: <3F98FF09.A87E7AFA@gmx.net> Message-ID: <20031024114716.GD12637@rogue.amk.ca> On Fri, Oct 24, 2003 at 12:29:29PM +0200, gfa2c wrote: > When I try to install distutils > with its setup.py, it ends in error > because something is missing. You're very vague about the problem. I'll take a leap in the dark and guess that you're on Windows; a very common problem is that most Windows machines don't have a compiler installed, so you're unable to install any Python package that includes a C extension. The solution is to get a compiler, unsurprisingly, or find a binary installer of the package. --amk From amk at amk.ca Fri Oct 24 12:11:51 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 24 12:11:57 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <200310221339.h9MDdNQQ025412@localhost.localdomain> References: <20031022133535.GA1837@rogue.amk.ca> <200310221339.h9MDdNQQ025412@localhost.localdomain> Message-ID: <20031024161151.GA14812@rogue.amk.ca> On Wed, Oct 22, 2003 at 11:39:23PM +1000, Anthony Baxter wrote: > and standard library? If so, what minimum version of python should I > code for? I figure either Py2.1 or Py2.3 - I see no reason to stop at > 2.2 - 2.3 is really just 2.2 with additional bugfixes &c. Last time this argument went around (in May) MAL argued for Python 2.0. I have no problem with that, though stopping at 2.2 also makes sense; it may be the old version, but it's still widely deployed. --amk From jeremy at zope.com Fri Oct 24 12:27:27 2003 From: jeremy at zope.com (Jeremy Hylton) Date: Fri Oct 24 12:28:44 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <20031024161151.GA14812@rogue.amk.ca> Message-ID: > On Wed, Oct 22, 2003 at 11:39:23PM +1000, Anthony Baxter wrote: > > and standard library? If so, what minimum version of python should I > > code for? I figure either Py2.1 or Py2.3 - I see no reason to stop at > > 2.2 - 2.3 is really just 2.2 with additional bugfixes &c. > > Last time this argument went around (in May) MAL argued for Python 2.0. > I have no problem with that, though stopping at 2.2 also makes sense; it may > be the old version, but it's still widely deployed. > > --amk +1 from me. I'm more in favor of more recent versions, but I'd be happy with anything that didn't need a future statement for nested scopes. Jeremy From mal at lemburg.com Fri Oct 24 16:01:24 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Fri Oct 24 16:01:43 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: References: Message-ID: <3F998514.8080905@lemburg.com> Jeremy Hylton wrote: >>On Wed, Oct 22, 2003 at 11:39:23PM +1000, Anthony Baxter wrote: >> >>>and standard library? If so, what minimum version of python should I >>>code for? I figure either Py2.1 or Py2.3 - I see no reason to stop at >>>2.2 - 2.3 is really just 2.2 with additional bugfixes &c. >> >>Last time this argument went around (in May) MAL argued for Python 2.0. >>I have no problem with that, though stopping at 2.2 also makes sense; it > > may > >>be the old version, but it's still widely deployed. >> >>--amk > > > +1 from me. > > I'm more in favor of more recent versions, but I'd be happy with anything > that didn't need a future statement for nested scopes. Where would you want to use nested scopes in distutils code ? Note that distutils code is not performance relevant. It's ease of customization and wide-spread usability that matters. You should be aware that package authors will be forced to drop Python >> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From bob at redivi.com Fri Oct 24 16:11:08 2003 From: bob at redivi.com (Bob Ippolito) Date: Fri Oct 24 16:11:47 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <3F998514.8080905@lemburg.com> References: <3F998514.8080905@lemburg.com> Message-ID: <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> On Oct 24, 2003, at 4:01 PM, M.-A. Lemburg wrote: > Jeremy Hylton wrote: >>> On Wed, Oct 22, 2003 at 11:39:23PM +1000, Anthony Baxter wrote: >>> >>>> and standard library? If so, what minimum version of python should I >>>> code for? I figure either Py2.1 or Py2.3 - I see no reason to stop >>>> at >>>> 2.2 - 2.3 is really just 2.2 with additional bugfixes &c. >>> >>> Last time this argument went around (in May) MAL argued for Python >>> 2.0. >>> I have no problem with that, though stopping at 2.2 also makes >>> sense; it >> may >>> be the old version, but it's still widely deployed. >>> >> +1 from me. >> I'm more in favor of more recent versions, but I'd be happy with >> anything >> that didn't need a future statement for nested scopes. > > Where would you want to use nested scopes in distutils code ? > Note that distutils code is not performance relevant. It's > ease of customization and wide-spread usability that > matters. > > You should be aware that package authors will be forced to drop > Python distutils. I wouldn't want to drop Python 2.1 support until > Python 2.3.3 is out (I plan to skip Python 2.2 altogether because > of the speed advantages that 2.3 has to offer :-). I find myself using nested scopes, generators, descriptors and new style classes quite a lot. It has nothing to do with performance, it's capability. There are a lot of occasions where generators can save you quite bit of code, provide more extensibility, or spare you from using threads. I'm never going to write another Python module/extension/etc. that goes out of its way to be Python 2.1 compatible, my vote is for 2.2.1 and later. -bob From slash at dotnetslash.net Fri Oct 24 20:55:21 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri Oct 24 20:55:25 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> Message-ID: On Fri, 24 Oct 2003, Bob Ippolito wrote: > On Oct 24, 2003, at 4:01 PM, M.-A. Lemburg wrote: > > > Where would you want to use nested scopes in distutils code ? > > Note that distutils code is not performance relevant. It's > > ease of customization and wide-spread usability that > > matters. > > > > You should be aware that package authors will be forced to drop > > Python > distutils. I wouldn't want to drop Python 2.1 support until > > Python 2.3.3 is out (I plan to skip Python 2.2 altogether because > > of the speed advantages that 2.3 has to offer :-). > > I find myself using nested scopes, generators, descriptors and new > style classes quite a lot. It has nothing to do with performance, it's > capability. There are a lot of occasions where generators can save you > quite bit of code, provide more extensibility, or spare you from using > threads. I'm never going to write another Python module/extension/etc. > that goes out of its way to be Python 2.1 compatible, my vote is for > 2.2.1 and later. Marc's point is that nested scopes are not necessary (although they could be useful) in distutils itself, therefore distutils should not require a high enough level just to be able to use nested scopes. Speaking as an admin of a fair number of machines, I've still got 1.5.2 running around. That's mostly because they're deprecated machines, just waiting for their last breath to give out. I would suspect, however, that large shops have a difficult time keeping the latest and greatest version of Python on all their machines (I do, and I do almost all admin stuff in python). If you've got lot's of things to do, and whatever version of Python you have installed works for everything you've deployed, it's just not a priority to upgrade. So my vote would be go for the _lowest_ version of Python that makes the Distutils code "comfortable". The higher version you require, the more package authors you alienate by _forcing_ them to drop support (or at least distutils support) for older versions. mwa -- Mark W. Alexander slash@dotnetslash.net From amk at amk.ca Fri Oct 24 21:31:02 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 24 21:31:10 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> Message-ID: <20031025013102.GA16782@rogue.amk.ca> On Fri, Oct 24, 2003 at 08:55:21PM -0400, Mark W. Alexander wrote: > Marc's point is that nested scopes are not necessary (although they > could be useful) in distutils itself, therefore distutils should not > require a high enough level just to be able to use nested scopes. It's actually not so much language features as new modules that are of interest. I have no great problems leaving the code base compatible with the 1.5.2 *language*; string methods, and perhaps 'print >>', would be convenient, but having them wouldn't make the Distutils code much shorter or better. On the other hand, Python 2.3 adds optparse, which might let us discard fancy_getopt, and the logging package would be useful for the output from Distutils commands. We could try to install the modules if the Distutils are being installed on a pre-2.3 version, but that would be a lot of trouble -- back-porting the modules, copying them into the distribution, etc. --amk From slash at dotnetslash.net Fri Oct 24 21:59:03 2003 From: slash at dotnetslash.net (Mark W. Alexander) Date: Fri Oct 24 21:59:07 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <20031025013102.GA16782@rogue.amk.ca> References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> <20031025013102.GA16782@rogue.amk.ca> Message-ID: On Fri, 24 Oct 2003 amk@amk.ca wrote: > On Fri, Oct 24, 2003 at 08:55:21PM -0400, Mark W. Alexander wrote: > > Marc's point is that nested scopes are not necessary (although they > > could be useful) in distutils itself, therefore distutils should not > > require a high enough level just to be able to use nested scopes. > > It's actually not so much language features as new modules that are of > interest. I have no great problems leaving the code base compatible with the > 1.5.2 *language*; string methods, and perhaps 'print >>', would be > convenient, but having them wouldn't make the Distutils code much shorter or > better. Right, that's what I meant to say you meant ;) > On the other hand, Python 2.3 adds optparse, which might let us discard > fancy_getopt, and the logging package would be useful for the output from > Distutils commands. We could try to install the modules if the Distutils > are being installed on a pre-2.3 version, but that would be a lot of trouble > -- back-porting the modules, copying them into the distribution, etc. Well, if the target for Distutils2 is 2.4, we could freeze Distutils1 for use with pre-2.4 implementations. Package authors could still target pre-2.4 Pythons using bdist* commands because the format of native binary packages shouldn't be changing, just the method of producing them. Although they _would_ have to make a conscious effort to limit there use of language features to their lowest supported Python version. Package users who need the features of a Distutils2 package that leverages new features would then be motivated to move to 2.4. That's the only reason I haven't upgraded so many of my machines: I haven't had to so I couldn't justify it. If I had to for new functionality, then the upgrade labor is justified. It's late. I'm tired. I hope that made sense... -- Mark W. Alexander slash@dotnetslash.net From amk at amk.ca Fri Oct 24 22:03:37 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 24 22:03:43 2003 Subject: [Distutils] Prepatory snapshot before Distutils 1.1 Message-ID: <20031025020337.GA16992@rogue.amk.ca> I want to make a Distutils 1.1 release that wraps up the version of the code in Python 2.3. This would be the last 1.5.2-compatible release, giving people the chance to use the code with versions of Python from 1.5.2 to 2.2. The README and related bits have been updated, and I've made a snapshot release that can be downloaded from http://www.python.org/sigs/distutils-sig/files/ If someone wants to try it with an older version of Python, please do and report any problems. If no bugs turn up, I'll wrap it up as the 1.1 final release, tag the CVS tree, and then we can start making 1.5.2-incompatible changes. --amk From robin at jessikat.fsnet.co.uk Sat Oct 25 05:21:43 2003 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Sat Oct 25 05:23:16 2003 Subject: [Distutils] darwin Python 2.1 problem Message-ID: In article <20031025060859.68323.qmail@web42002.mail.yahoo.com>, Chris Leonello writes >I am trying to build _renderPM.so for use with Python 2.1.3 in a Zope >2.6.2 installation on a Mac OS X Jaguar (10.2.8). I recieve the following >error: > >creating build/lib.darwin-6.8-Power Macintosh-2.1 >gcc -flat_namespace -bundle -undefined suppress >build/temp.darwin-6.8-Power Macintosh-2.1/_renderPM.o >-Lbuild/temp.darwin-6.8-Power Macintosh-2.1 -l_renderPM_libart >-l_renderPM_gt1 -o build/lib.darwin-6.8-Power Macintosh-2.1/_renderPM.so >ld: archive: build/temp.darwin-6.8-Power >Macintosh-2.1/lib_renderPM_libart.a has no table of contents, add one with >ranlib(1) (can't load from it) >ld: archive: build/temp.darwin-6.8-Power Macintosh-2.1/lib_renderPM_gt1.a >has no table of contents, add one with ranlib(1) (can't load from it) >error: command 'gcc' failed with exit status 1 Is there any way to make static library builds do a ranlib? Some Mac users say there's a problem with 2.1. -- Robin Becker From bob at redivi.com Sat Oct 25 11:29:30 2003 From: bob at redivi.com (Bob Ippolito) Date: Sat Oct 25 11:30:39 2003 Subject: [Distutils] darwin Python 2.1 problem In-Reply-To: References: Message-ID: <06D1C81B-0700-11D8-9DA8-000A95686CD8@redivi.com> On Oct 25, 2003, at 5:21 AM, Robin Becker wrote: > In article <20031025060859.68323.qmail@web42002.mail.yahoo.com>, Chris > Leonello writes >> I am trying to build _renderPM.so for use with Python 2.1.3 in a Zope >> 2.6.2 installation on a Mac OS X Jaguar (10.2.8). I recieve the >> following >> error: >> >> creating build/lib.darwin-6.8-Power Macintosh-2.1 >> gcc -flat_namespace -bundle -undefined suppress >> build/temp.darwin-6.8-Power Macintosh-2.1/_renderPM.o >> -Lbuild/temp.darwin-6.8-Power Macintosh-2.1 -l_renderPM_libart >> -l_renderPM_gt1 -o build/lib.darwin-6.8-Power >> Macintosh-2.1/_renderPM.so >> ld: archive: build/temp.darwin-6.8-Power >> Macintosh-2.1/lib_renderPM_libart.a has no table of contents, add one >> with >> ranlib(1) (can't load from it) >> ld: archive: build/temp.darwin-6.8-Power >> Macintosh-2.1/lib_renderPM_gt1.a >> has no table of contents, add one with ranlib(1) (can't load from it) >> error: command 'gcc' failed with exit status 1 > > Is there any way to make static library builds do a ranlib? Some Mac > users say there's a problem with 2.1. There's some kind of patch (you should even be able to do it from your setup.py) you can do to distutils to make it always run ranlib, but you can also just ranlib build/temp*/*.a and then start the build again and it should work. *NOBODY* should be using pre-2.3 Python on Darwin, though. -bob From robin at jessikat.fsnet.co.uk Sat Oct 25 13:23:47 2003 From: robin at jessikat.fsnet.co.uk (Robin Becker) Date: Sat Oct 25 13:23:57 2003 Subject: [Distutils] darwin Python 2.1 problem In-Reply-To: <06D1C81B-0700-11D8-9DA8-000A95686CD8@redivi.com> References: <06D1C81B-0700-11D8-9DA8-000A95686CD8@redivi.com> Message-ID: In article <06D1C81B-0700-11D8-9DA8-000A95686CD8@redivi.com>, Bob Ippolito writes ...... >> Is there any way to make static library builds do a ranlib? Some Mac >> users say there's a problem with 2.1. > >There's some kind of patch (you should even be able to do it from your >setup.py) you can do to distutils to make it always run ranlib, but you >can also just ranlib build/temp*/*.a and then start the build again and >it should work. > >*NOBODY* should be using pre-2.3 Python on Darwin, though. > >-bob ..... I suppose that's Zope related. I seem to remember they were on 2.1. -- Robin Becker From Jack.Jansen at cwi.nl Sat Oct 25 18:34:12 2003 From: Jack.Jansen at cwi.nl (Jack Jansen) Date: Sat Oct 25 18:34:16 2003 Subject: [Distutils] chicken and egg? In-Reply-To: <20031024114716.GD12637@rogue.amk.ca> References: <3F98FF09.A87E7AFA@gmx.net> <20031024114716.GD12637@rogue.amk.ca> Message-ID: <5B52B478-073B-11D8-B873-000A27B19B96@cwi.nl> On 24-okt-03, at 13:47, amk@amk.ca wrote: > On Fri, Oct 24, 2003 at 12:29:29PM +0200, gfa2c wrote: >> When I try to install distutils >> with its setup.py, it ends in error >> because something is missing. > > You're very vague about the problem. I'll take a leap in the dark and > guess > that you're on Windows; a very common problem is that most Windows > machines > don't have a compiler installed, so you're unable to install any Python > package that includes a C extension. The solution is to get a > compiler, > unsurprisingly, or find a binary installer of the package. Whether or not this is the original problem: it definitely deserves a good and clear error message. Especially people who don't have a development system installed probably won't know what they miss, or what a development system is, or why they would need one. -- Jack Jansen, , http://www.cwi.nl/~jack If I can't dance I don't want to be part of your revolution -- Emma Goldman From seefeld at sympatico.ca Sat Oct 25 19:02:42 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Sat Oct 25 19:05:25 2003 Subject: [Distutils] chicken and egg? In-Reply-To: <5B52B478-073B-11D8-B873-000A27B19B96@cwi.nl> References: <3F98FF09.A87E7AFA@gmx.net> <20031024114716.GD12637@rogue.amk.ca> <5B52B478-073B-11D8-B873-000A27B19B96@cwi.nl> Message-ID: <3F9B0112.8020503@sympatico.ca> Jack Jansen wrote: > Whether or not this is the original problem: it definitely deserves a good > and clear error message. indeed. And to help out here we need a good and clear problem report. What was the (unclear) error message the original poster couldn't interpret ? What system / python installation did he run on ? Regards, Stefan From mwh at python.net Mon Oct 27 05:45:22 2003 From: mwh at python.net (Michael Hudson) Date: Mon Oct 27 05:45:33 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: (Mark W. Alexander's message of "Fri, 24 Oct 2003 20:55:21 -0400 (EDT)") References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> Message-ID: <2mllr7m01p.fsf@starship.python.net> "Mark W. Alexander" writes: > Speaking as an admin of a fair number of machines, I've still got 1.5.2 > running around. How likely are you to try to upgrade the distutils install on those machines? How often do you even install new Python packages on them? These are the questions that matter, not whether people still *run* 1.5.2. Cheers, mwh -- On the other hand, the following areas are subject to boycott in reaction to the rampant impurity of design or execution, as determined after a period of study, in no particular order: ... http://www.naggum.no/profile.html From mal at lemburg.com Mon Oct 27 06:03:39 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Oct 27 06:03:46 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <2mllr7m01p.fsf@starship.python.net> References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> <2mllr7m01p.fsf@starship.python.net> Message-ID: <3F9CFB8B.60702@lemburg.com> Michael Hudson wrote: > "Mark W. Alexander" writes: > >>Speaking as an admin of a fair number of machines, I've still got 1.5.2 >>running around. > > How likely are you to try to upgrade the distutils install on those > machines? How often do you even install new Python packages on them? > These are the questions that matter, not whether people still *run* > 1.5.2. Not really: when you want to build a distutils package you do need to run the target Python version and that's where the distutils compatibility matters. FWIW, eGenix still ships 1.5.2 compatible packages and we use the CVS version of distutils to built the binary packages. We will drop 1.5.2 support for versions 2.2 of the packages (2.1 currently in beta, still waiting to be announced) and then move on to Python 2.1 as minimum requirement for new releases. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Oct 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mwh at python.net Mon Oct 27 07:17:57 2003 From: mwh at python.net (Michael Hudson) Date: Mon Oct 27 07:18:05 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <3F9CFB8B.60702@lemburg.com> (M.'s message of "Mon, 27 Oct 2003 12:03:39 +0100") References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> <2mllr7m01p.fsf@starship.python.net> <3F9CFB8B.60702@lemburg.com> Message-ID: <2mbrs2nabu.fsf@starship.python.net> "M.-A. Lemburg" writes: > Michael Hudson wrote: >> "Mark W. Alexander" writes: >> >>>Speaking as an admin of a fair number of machines, I've still got 1.5.2 >>> running around. >> How likely are you to try to upgrade the distutils install on those >> machines? How often do you even install new Python packages on them? >> These are the questions that matter, not whether people still *run* >> 1.5.2. > > Not really: when you want to build a distutils package > you do need to run the target Python version and that's > where the distutils compatibility matters. Ah, I see. I suppose you could install an *old* distutils over (say) 2.4, but that would be pretty nasty. Cheers, mwh -- A witty saying proves nothing. -- Voltaire From anthony at interlink.com.au Mon Oct 27 08:33:54 2003 From: anthony at interlink.com.au (Anthony Baxter) Date: Mon Oct 27 08:38:00 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <3F9CFB8B.60702@lemburg.com> Message-ID: <200310271334.h9RDXsam004638@localhost.localdomain> >>> "M.-A. Lemburg" wrote > FWIW, eGenix still ships 1.5.2 compatible packages and we use > the CVS version of distutils to built the binary packages. > We will drop 1.5.2 support for versions 2.2 of the packages > (2.1 currently in beta, still waiting to be announced) and > then move on to Python 2.1 as minimum requirement for > new releases. Could you perhaps give us a breakdown of the percentage of people in say, the last 3 months, that have downloaded the various packages by Python version? This would be (to me, anyway) a good way to get an idea of how many folks with 1.5.2 are still installing new versions of packages. My gut feel is that while there's probably plenty of people out there with 1.5.2 deployed and in use, the numbers of them actually installing new packages will be considerably smaller. Personally, I'd _love_ to move to 2.3 for the logging and optparse packages alone - perhaps we could ship a version with logging and optparse included for 2.1 and 2.2. (And, ideally, once pypi gets dependency tracking, we could make all this magically happen...) Anthony -- Anthony Baxter It's never too late to have a happy childhood. From Paul.Moore at atosorigin.com Mon Oct 27 08:42:42 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Mon Oct 27 08:43:26 2003 Subject: [Distutils] Timeframe of 2.0 again? Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060CF6@UKDCX001.uk.int.atosorigin.com> From: Anthony Baxter [mailto:anthony@interlink.com.au] >>> "M.-A. Lemburg" wrote > FWIW, eGenix still ships 1.5.2 compatible packages and we use > the CVS version of distutils to built the binary packages. I'm probably being dense here, but why don't you use the version of distutils that came with Python (or for Python versions before distutils was in the standard library, a fixed distutils version compatible with that Python version) to build the binary packages? It may be more complex to keep the build environment set up, but surely that's a one-off cost to the distributor, rather than a significant reason for constraining the development of distutils? Paul. From mal at lemburg.com Mon Oct 27 09:03:37 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Oct 27 09:03:46 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060CF6@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060CF6@UKDCX001.uk.int.atosorigin.com> Message-ID: <3F9D25B9.7090909@lemburg.com> Moore, Paul wrote: > From: Anthony Baxter [mailto:anthony@interlink.com.au] > >>>>"M.-A. Lemburg" wrote >> >>FWIW, eGenix still ships 1.5.2 compatible packages and we use >>the CVS version of distutils to built the binary packages. > > I'm probably being dense here, but why don't you use the version > of distutils that came with Python (or for Python versions before > distutils was in the standard library, a fixed distutils version > compatible with that Python version) to build the binary packages? > > It may be more complex to keep the build environment set up, but > surely that's a one-off cost to the distributor, rather than a > significant reason for constraining the development of distutils? Not so: in that case we'd have to keep in sync with at least 5 different versions of distutils deployed out there. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Oct 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Paul.Moore at atosorigin.com Mon Oct 27 09:23:40 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Mon Oct 27 09:24:25 2003 Subject: [Distutils] Timeframe of 2.0 again? Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060CF7@UKDCX001.uk.int.atosorigin.com> From: M.-A. Lemburg [mailto:mal@lemburg.com] > Not so: in that case we'd have to keep in sync with at > least 5 different versions of distutils deployed out there. I'm sure I am missing something, so please forgive me if I'm labouring the obvious, but can't you retain all your current build environments (Python 1.5.2, 2.0, 2.1, 2.2, 2.3) and when 2.4 comes out just add that, and only use the new distutils with 2.4? [I'm wondering - is the thing I'm missing that you're using a single shared distutils with all of the Python versions? I can't see how that would work...] Or are you worried about setup.py not working with both the old and new distutils? That's a valid issue, but I'd assume that the new distutils would have to be careful not to break compatibility with old setup.py files. Once again, apologies if I'm being dense. My experience of distributing Python modules is nothing compared to yours, and I don't mean to imply that I think your concerns are invalid. I'm just interested in understanding the issue I've missed, so that I don't fall into the trap of assuming things are simpler than they really are :-) Paul From bob at redivi.com Mon Oct 27 09:26:10 2003 From: bob at redivi.com (Bob Ippolito) Date: Mon Oct 27 09:26:42 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <3F9D25B9.7090909@lemburg.com> References: <16E1010E4581B049ABC51D4975CEDB8803060CF6@UKDCX001.uk.int.atosorigin.com> <3F9D25B9.7090909@lemburg.com> Message-ID: <82B3131E-0889-11D8-A5DF-000A95686CD8@redivi.com> On Oct 27, 2003, at 9:03 AM, M.-A. Lemburg wrote: > Moore, Paul wrote: >> From: Anthony Baxter [mailto:anthony@interlink.com.au] >>>>> "M.-A. Lemburg" wrote >>> >>> FWIW, eGenix still ships 1.5.2 compatible packages and we use >>> the CVS version of distutils to built the binary packages. >> I'm probably being dense here, but why don't you use the version >> of distutils that came with Python (or for Python versions before >> distutils was in the standard library, a fixed distutils version >> compatible with that Python version) to build the binary packages? >> It may be more complex to keep the build environment set up, but >> surely that's a one-off cost to the distributor, rather than a >> significant reason for constraining the development of distutils? > > Not so: in that case we'd have to keep in sync with at > least 5 different versions of distutils deployed out there. Would it be prohibitively hard to maintain two versions of your setup.py file? One for distutils pre-2.0, and one for 2.0? Pre-2.2 platforms would be supported by distutils pre-2.0, and everything else would be on 2.0. I can't imagine that there will be too many people that still need *new* pre-2.2 packages by the time that distutils 2.0 exists. -bob From amk at amk.ca Mon Oct 27 09:30:29 2003 From: amk at amk.ca (amk@amk.ca) Date: Mon Oct 27 09:30:46 2003 Subject: [Distutils] CWD when running compilers Message-ID: <20031027143029.GA28815@rogue.amk.ca> I've come across a situation that may be a Distutils bug, but I'm unsure if it's a bug or not. When Distutils runs a compiler subprocess, the current working directory is left alone so, in the absence of os.chdir() calls in the setup.py, it's the same directory as the setup.py script. If the source file is in a subdirectory (e.g. src/constants.c), the CWD is therefore different from the directory containing the source file. In C you can use relative #include paths, e.g. #include <../../hydra/mbv_sched/common.h>. If the source file contains such a relative #include, it's natural to start from the directory containing the header or the source file; this is wrong, however. Question: is this a bug in Distutils? Should distutils.spawn change the CWD to the same directory as the source? --amk From seefeld at sympatico.ca Mon Oct 27 09:45:42 2003 From: seefeld at sympatico.ca (Stefan Seefeld) Date: Mon Oct 27 09:46:33 2003 Subject: [Distutils] CWD when running compilers References: <20031027143029.GA28815@rogue.amk.ca> Message-ID: amk@amk.ca wrote: > I've come across a situation that may be a Distutils bug, but I'm unsure > if it's a bug or not. > > When Distutils runs a compiler subprocess, the current working directory is > left alone so, in the absence of os.chdir() calls in the setup.py, it's the > same directory as the setup.py script. If the source file is in a > subdirectory (e.g. src/constants.c), the CWD is therefore different from the > directory containing the source file. > > In C you can use relative #include paths, e.g. #include > <../../hydra/mbv_sched/common.h>. If the source file contains such a > relative #include, it's natural to start from the directory containing the > header or the source file; this is wrong, however. > > Question: is this a bug in Distutils? Should distutils.spawn change the CWD > to the same directory as the source? In my own projects I'v always treated the source tree as read-only, i.e. I generally build in a 'build tree' that lives outside the source tree. Therefor, I never use relative include statements (for this and other reasons). As this is an issue only the authors of extension modules can address, I think it would be best if distutils could adapt to the different models. I believe the current way is fine, but I don't think distutils should impose any particular build system design. In a nutshell: it's not a bug, just a restriction (which distutils is already full of anyways). Regards, Stefan From mal at lemburg.com Mon Oct 27 09:53:01 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Oct 27 09:53:08 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060CF7@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060CF7@UKDCX001.uk.int.atosorigin.com> Message-ID: <3F9D314D.5030206@lemburg.com> Moore, Paul wrote: > From: M.-A. Lemburg [mailto:mal@lemburg.com] > >>Not so: in that case we'd have to keep in sync with at >>least 5 different versions of distutils deployed out there. > > > I'm sure I am missing something, so please forgive me if I'm > labouring the obvious, but can't you retain all your current > build environments (Python 1.5.2, 2.0, 2.1, 2.2, 2.3) and when > 2.4 comes out just add that, and only use the new distutils > with 2.4? > > [I'm wondering - is the thing I'm missing that you're using a > single shared distutils with all of the Python versions? I > can't see how that would work...] As I said before, we are using distutils CVS for all Python versions we support. > Or are you worried about setup.py not working with both the old > and new distutils? That's a valid issue, but I'd assume that > the new distutils would have to be careful not to break > compatibility with old setup.py files. Right. We are adding many features to distutils which we need for supporting features like, e.g. automatic configuration, etc. These features rely heavily on subclassing and the way distutils is tied together. Supporting the more than 5 versions out there is not feasable in this kind of setup which is typical of distutils packaging, since distutils is designed to be extended in this way. > Once again, apologies if I'm being dense. My experience of > distributing Python modules is nothing compared to yours, and > I don't mean to imply that I think your concerns are invalid. > I'm just interested in understanding the issue I've missed, so > that I don't fall into the trap of assuming things are simpler > than they really are :-) I wouldn't mind having distutils optionally use features from 2.3 or 2.4, it's just that the code for supporting older versions than 2.1 should, IMHO, not be removed from the package. -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Oct 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From mal at lemburg.com Mon Oct 27 09:58:12 2003 From: mal at lemburg.com (M.-A. Lemburg) Date: Mon Oct 27 09:58:19 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <200310271334.h9RDXsam004638@localhost.localdomain> References: <200310271334.h9RDXsam004638@localhost.localdomain> Message-ID: <3F9D3284.8020205@lemburg.com> Anthony Baxter wrote: >>>>"M.-A. Lemburg" wrote >> >>FWIW, eGenix still ships 1.5.2 compatible packages and we use >>the CVS version of distutils to built the binary packages. >>We will drop 1.5.2 support for versions 2.2 of the packages >>(2.1 currently in beta, still waiting to be announced) and >>then move on to Python 2.1 as minimum requirement for >>new releases. > > > Could you perhaps give us a breakdown of the percentage of people in > say, the last 3 months, that have downloaded the various packages by > Python version? This would be (to me, anyway) a good way to get an > idea of how many folks with 1.5.2 are still installing new versions > of packages. My gut feel is that while there's probably plenty of > people out there with 1.5.2 deployed and in use, the numbers of them > actually installing new packages will be considerably smaller. Sure, but if you want to support older versions, you sometimes also have to ship new packages to these users, e.g. to fix bugs. Here's a breakdown of the downloads we had for 2003 so far: Package Python 1.5.2 Python 2.0 Python 2.1 egenix-mx-base 4.27% 2.09% 8.73% Package Python 2.2 Python 2.3 egenix-mx-base 44.12% 10.08% Package Source ZIP Source TAR.GZ egenix-mx-base 4.34% 26.38% It's hard to tell how big the current installed user base is, but the fact that people are still downloading older versions underlines the fact that people are still running these (Python 1.5.2 is still one of the fastest Python versions around, BTW; only Python 2.3 can catch up with its performance, Python 2.2 is a nightmare compared to it). > Personally, I'd _love_ to move to 2.3 for the logging and optparse > packages alone - perhaps we could ship a version with logging and > optparse included for 2.1 and 2.2. > > (And, ideally, once pypi gets dependency tracking, we could make > all this magically happen...) Why not make all these features optional and dependent on the version running distutils ? -- Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Oct 27 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! :::: From Paul.Moore at atosorigin.com Mon Oct 27 10:46:21 2003 From: Paul.Moore at atosorigin.com (Moore, Paul) Date: Mon Oct 27 10:47:06 2003 Subject: [Distutils] Timeframe of 2.0 again? Message-ID: <16E1010E4581B049ABC51D4975CEDB8803060CF9@UKDCX001.uk.int.atosorigin.com> From: M.-A. Lemburg [mailto:mal@lemburg.com] >> [I'm wondering - is the thing I'm missing that you're using a >> single shared distutils with all of the Python versions? I >> can't see how that would work...] > As I said before, we are using distutils CVS for all Python > versions we support. But I assume you install CVS distutils for all the Pythons, and therefore *could* (but see below) install different versions (and by implication freeze the distutils version used with a given Python). >> Or are you worried about setup.py not working with both the old >> and new distutils? That's a valid issue, but I'd assume that >> the new distutils would have to be careful not to break >> compatibility with old setup.py files. > Right. We are adding many features to distutils which we > need for supporting features like, e.g. automatic configuration, > etc. These features rely heavily on subclassing and the > way distutils is tied together. Supporting the more than > 5 versions out there is not feasable in this kind of setup > which is typical of distutils packaging, since distutils > is designed to be extended in this way. OK, so you are talking about compatibility at the setup.py level. In that case, I agree entirely - whatever changes are made to distutils should be done very carefully to avoid breaking existing setup.py scripts. Having said that, it would be nice if the distutils documentation was complete enough that it was feasible to say "we reserve the right to break anything that isn't documented". In many ways, that should be the number 1 priority for distutils, complete documentation of the API. I'd imagine that there is a nasty grey area where seriously complex setup.py scripts will need to be deemed as "getting too chummy with the internals", and breakage will be necessary. Maybe there's a need for a staged approach (lots more documentation, plus some official deprecation - for example, things like fancy_getopt - in 2.4, with the API cleanup being left to 2.5). Thanks for clarifying, Paul. From fdrake at acm.org Mon Oct 27 16:44:09 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Mon Oct 27 16:44:17 2003 Subject: [Distutils] Changes in RPM affecting Distutils Message-ID: <16285.37289.146923.209516@grendel.zope.com> I just tried building an RPM using the bdist_rpm command to setup.py, and the rpm process complained. Appearantly newer versions of rpm use a separate build process, rpmbuild, and don't provide sufficient command line compatibility by default. I'm using rpm 4.2 on a RedHat 9 system. Has anyone looked into fixing this in Distutils yet? -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mwa at anonymoose.net Mon Oct 27 22:26:09 2003 From: mwa at anonymoose.net (Mark W. Alexander) Date: Mon Oct 27 22:26:54 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <2mllr7m01p.fsf@starship.python.net> References: <3F998514.8080905@lemburg.com> <34758E1A-065E-11D8-9B7B-000A95686CD8@redivi.com> <2mllr7m01p.fsf@starship.python.net> Message-ID: On Mon, 27 Oct 2003, Michael Hudson wrote: > "Mark W. Alexander" writes: > > > Speaking as an admin of a fair number of machines, I've still got 1.5.2 > > running around. > > How likely are you to try to upgrade the distutils install on those > machines? How often do you even install new Python packages on them? > These are the questions that matter, not whether people still *run* > 1.5.2. Not at all likely to upgrade the distutils, but reasonably likely to add new packages. The problem that might arise is that I need a new package, but the setup.py for that package is in Distutils2 format. But as I noted, I think 1.5.2 is just something that people in my position will have to cope with. If the need for a Distutils2 pacakge arises, then I'd upgrade to the latest Python anyway. At 2.0 on, the decision gets a little fuzzier. mwa -- Mark W. Alexander slash@dotnetslash.net From mwa at anonymoose.net Mon Oct 27 22:37:20 2003 From: mwa at anonymoose.net (Mark W. Alexander) Date: Mon Oct 27 22:37:24 2003 Subject: [Distutils] Timeframe of 2.0 again? In-Reply-To: <16E1010E4581B049ABC51D4975CEDB8803060CF9@UKDCX001.uk.int.atosorigin.com> References: <16E1010E4581B049ABC51D4975CEDB8803060CF9@UKDCX001.uk.int.atosorigin.com> Message-ID: On Mon, 27 Oct 2003, Moore, Paul wrote: > > Right. We are adding many features to distutils which we > > need for supporting features like, e.g. automatic configuration, > > etc. These features rely heavily on subclassing and the > > way distutils is tied together. Supporting the more than > > 5 versions out there is not feasable in this kind of setup > > which is typical of distutils packaging, since distutils > > is designed to be extended in this way. > > OK, so you are talking about compatibility at the setup.py level. > In that case, I agree entirely - whatever changes are made to > distutils should be done very carefully to avoid breaking existing > setup.py scripts. That's my concern as well. > Having said that, it would be nice if the distutils documentation > was complete enough that it was feasible to say "we reserve the > right to break anything that isn't documented". In many ways, > that should be the number 1 priority for distutils, complete > documentation of the API. Amen. But until the API is fully documented there are a lot of, uhm, "creative" setup.py's out there. > I'd imagine that there is a nasty grey area where seriously complex > setup.py scripts will need to be deemed as "getting too chummy with > the internals", and breakage will be necessary. Maybe there's a > need for a staged approach (lots more documentation, plus some > official deprecation - for example, things like fancy_getopt - in > 2.4, with the API cleanup being left to 2.5). Those "seriously complex" setup.py scripts are a great place to get ideas about what features package authors really need in Distutils2. Anything that looks "too chummy" means there probably needs to be a more abstract method to accomplish what's being done. mwa -- Mark W. Alexander slash@dotnetslash.net From mwa at anonymoose.net Mon Oct 27 22:56:41 2003 From: mwa at anonymoose.net (Mark W. Alexander) Date: Mon Oct 27 22:56:45 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <16285.37289.146923.209516@grendel.zope.com> References: <16285.37289.146923.209516@grendel.zope.com> Message-ID: On Mon, 27 Oct 2003, Fred L. Drake, Jr. wrote: > > I just tried building an RPM using the bdist_rpm command to setup.py, > and the rpm process complained. Appearantly newer versions of rpm use > a separate build process, rpmbuild, and don't provide sufficient > command line compatibility by default. > > I'm using rpm 4.2 on a RedHat 9 system. > > Has anyone looked into fixing this in Distutils yet? Looked at, no. Thought about, yes. What I've been thinking about (in my complete ignorance of the rpmlib package) is that building rpms would be better done using the rpmlib package rather than external rpm commands. I'd like to see equivalent packager libraries for all bdist commands, i.e. winlib, pkglib, dpkglib, sduxlib, etc. There's nothing real magic about the format of binary packages that the have to be _created_ by the native package tools. They only need to be able to be read by native package tools. If we can include/build such a library for each binary packager, then binary packages can be created on one platform for another (binary compatible) platform. If we add in cross-compiler support, then binary packages for ALL supported platforms could be created on any platform with the appropriate cross-toolchains. (And I recently found an unofficial apt repository with a lot of cross toolchains.) The idea that really intriques me is being able to upload source to a catalog host with a full cross-compile suite and multiple python versions. When someone requests to download a binary package for python 2.2 for a Sparc sun4u that uses pkgtool, the catalog would see if it had one available and, if not, schedule the build and have the request try back later. Binary packages not downloaded again within a certain period of time could be expired and flushed to save space as necessary. Also, cross-compiling capability would be a huge advantage for targeting packages for embedded systems. I love having python on my Zaurus, but building packages with C extensions for it right now means installing a full development environment on it, or losing all the ease of Distutils. -- Mark W. Alexander slash@dotnetslash.net From amk at amk.ca Tue Oct 28 07:42:32 2003 From: amk at amk.ca (amk@amk.ca) Date: Tue Oct 28 07:42:39 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <16285.37289.146923.209516@grendel.zope.com> References: <16285.37289.146923.209516@grendel.zope.com> Message-ID: <20031028124232.GA1095@rogue.amk.ca> On Mon, Oct 27, 2003 at 04:44:09PM -0500, Fred L. Drake, Jr. wrote: > Has anyone looked into fixing this in Distutils yet? It's supposed to be fixed; from bdist_rpm.run(): rpm_cmd = ['rpm'] if os.path.exists('/usr/bin/rpmbuild') or \ os.path.exists('/bin/rpmbuild'): rpm_cmd = ['rpmbuild'] Is rpmbuild somewhere else? --amk From fdrake at acm.org Tue Oct 28 08:49:50 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Oct 28 08:49:57 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <20031028124232.GA1095@rogue.amk.ca> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> Message-ID: <16286.29694.868380.104891@grendel.zope.com> amk@amk.ca writes: > It's supposed to be fixed; from bdist_rpm.run(): > > rpm_cmd = ['rpm'] > if os.path.exists('/usr/bin/rpmbuild') or \ > os.path.exists('/bin/rpmbuild'): > rpm_cmd = ['rpmbuild'] > > Is rpmbuild somewhere else? No; I see what happened now. Someone fixed Distutils to use rpmbuild, but didn't backport it to the Python 2.1 I was using at the time. ;-) I guess this is why Marc-Andre uses the latest distutils for all Python versions, and sheds real light on why Distutils itself should remain as Python-version-agnostic as possible. It's needed for packagers to support current platforms, not just older versions of Python. For all-Python packages it's not a big problem, but is more of a problem when C extensions are involved. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From amk at amk.ca Tue Oct 28 09:16:03 2003 From: amk at amk.ca (amk@amk.ca) Date: Tue Oct 28 09:16:08 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <16286.29694.868380.104891@grendel.zope.com> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> <16286.29694.868380.104891@grendel.zope.com> Message-ID: <20031028141603.GA1444@rogue.amk.ca> On Tue, Oct 28, 2003 at 08:49:50AM -0500, Fred L. Drake, Jr. wrote: > No; I see what happened now. Someone fixed Distutils to use rpmbuild, > but didn't backport it to the Python 2.1 I was using at the time. ;-) It would be possible to backport (well, copy really) the current Distutils tree to the various -maint branches, but it would be a lot of work. You could grab the 1.1 snapshot from www.python.org/sigs/distutils-sig/files/ and install it. BTW, I've gotten no comments on the snapshot -- has anyone tried it? > I guess this is why Marc-Andre uses the latest distutils for all > Python versions, and sheds real light on why Distutils itself should > remain as Python-version-agnostic as possible. It's needed for Well, we need to come to some decision on this, but it's not clear how. Should we ask Guido, or python-dev, or the PBF? Should we vote on it? If it's up to the Distutils maintainer -- and I'm probably the closest approximation at this time -- then I would say 2.0; MAL's arguments are convincing to me, even though personally I'd find 2.3 more convenient. --amk From fdrake at acm.org Tue Oct 28 10:51:20 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Oct 28 10:51:28 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <20031028141603.GA1444@rogue.amk.ca> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> <16286.29694.868380.104891@grendel.zope.com> <20031028141603.GA1444@rogue.amk.ca> Message-ID: <16286.36984.457762.195409@grendel.zope.com> amk@amk.ca writes: > It would be possible to backport (well, copy really) the current Distutils > tree to the various -maint branches, but it would be a lot of work. You Why would dropping the current code onto the maintenance branches be a lot of work? It shouldn't be more than (maybe) some "cvs add"s and a commit. > Well, we need to come to some decision on this, but it's not clear how. > Should we ask Guido, or python-dev, or the PBF? Should we vote on it? I suspect it's really up to whoever does the work (including testing). > If it's up to the Distutils maintainer -- and I'm probably the closest > approximation at this time -- then I would say 2.0; MAL's arguments are > convincing to me, even though personally I'd find 2.3 more convenient. I'd be glad to see it support back to 2.0, however tedious writing code may be at times. Most of the tedium is a matter of remembering what we didn't have back then! -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From jafo at tummy.com Tue Oct 28 12:11:26 2003 From: jafo at tummy.com (Sean Reifschneider) Date: Tue Oct 28 12:14:22 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <20031028124232.GA1095@rogue.amk.ca> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> Message-ID: <20031028171126.GB7837@tummy.com> On Tue, Oct 28, 2003 at 07:42:32AM -0500, amk@amk.ca wrote: >On Mon, Oct 27, 2003 at 04:44:09PM -0500, Fred L. Drake, Jr. wrote: >> Has anyone looked into fixing this in Distutils yet? > >It's supposed to be fixed; from bdist_rpm.run(): It's actually something that I think Red Hat should have released an errata for. I submitted a bug report including a patch into their bugzilla probably 6 months ago, and it was closed with a "A fixed RPM is provided on this guy's page". I wasn't impressed with the response. Sean -- "All I'm saying is that when I'm around you I find myself showing off, which is the idiots version of being interesting." -- _LA_Story_ Sean Reifschneider, Member of Technical Staff tummy.com, ltd. - Linux Consulting since 1995. Qmail, Python, SysAdmin From amk at amk.ca Tue Oct 28 12:51:58 2003 From: amk at amk.ca (amk@amk.ca) Date: Tue Oct 28 12:52:05 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <16286.36984.457762.195409@grendel.zope.com> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> <16286.29694.868380.104891@grendel.zope.com> <20031028141603.GA1444@rogue.amk.ca> <16286.36984.457762.195409@grendel.zope.com> Message-ID: <20031028175158.GA2274@rogue.amk.ca> On Tue, Oct 28, 2003 at 10:51:20AM -0500, Fred L. Drake, Jr. wrote: > Why would dropping the current code onto the maintenance branches be a > lot of work? It shouldn't be more than (maybe) some "cvs add"s and a > commit. We can't do that without breaking the policy that maintenance branches have no new features (e.g. 2.3's register command, various changed options on bdist_rpm, doubtless). If Distutils can add new features, why not other modules? It would be possible to go through the CVS logs and tease apart which changes are just bugfixes, but someone would need to volunteer to do that, and it would be a lot of tedious work that only benefited old Python versions. --amk From fdrake at acm.org Tue Oct 28 13:07:49 2003 From: fdrake at acm.org (Fred L. Drake, Jr.) Date: Tue Oct 28 13:08:09 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <20031028175158.GA2274@rogue.amk.ca> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> <16286.29694.868380.104891@grendel.zope.com> <20031028141603.GA1444@rogue.amk.ca> <16286.36984.457762.195409@grendel.zope.com> <20031028175158.GA2274@rogue.amk.ca> Message-ID: <16286.45173.61355.280739@grendel.zope.com> amk@amk.ca writes: > We can't do that without breaking the policy that maintenance branches have > no new features (e.g. 2.3's register command, various changed options on > bdist_rpm, doubtless). If Distutils can add new features, why not other > modules? That falls into the "I agree in principal, but..." category for me. I generally think of distutils as a feature, not parts of it. If pieces of it are features, then "working with current RPM versions" is a feature to, so the compatibility can't be backported in any case. The "email" package, on the other hand, gets updated as a chunk. > It would be possible to go through the CVS logs and tease apart which > changes are just bugfixes, but someone would need to volunteer to do that, > and it would be a lot of tedious work that only benefited old Python > versions. I agree that this is a lot of work, and it's not clear that it's the right thing. -Fred -- Fred L. Drake, Jr. PythonLabs at Zope Corporation From mwa at anonymoose.net Tue Oct 28 13:08:30 2003 From: mwa at anonymoose.net (Mark W. Alexander) Date: Tue Oct 28 13:08:33 2003 Subject: [Distutils] Changes in RPM affecting Distutils In-Reply-To: <20031028141603.GA1444@rogue.amk.ca> References: <16285.37289.146923.209516@grendel.zope.com> <20031028124232.GA1095@rogue.amk.ca> <16286.29694.868380.104891@grendel.zope.com> <20031028141603.GA1444@rogue.amk.ca> Message-ID: On Tue, 28 Oct 2003 amk@amk.ca wrote: > Well, we need to come to some decision on this, but it's not clear how. > Should we ask Guido, or python-dev, or the PBF? Should we vote on it? > > If it's up to the Distutils maintainer -- and I'm probably the closest > approximation at this time -- then I would say 2.0; MAL's arguments are > convincing to me, even though personally I'd find 2.3 more convenient. This satisfies my concerns. I think it should be generally accepted that Distutils needs to support the current version of Python - X for all the reasons discussed. Maybe X will vary and we have to think it through each release, or X can be static and define the cut-off that package authors have to commit to to leverage Distutils. Forcing X<=1, however, would be a bad idea. mwa -- Mark W. Alexander slash@dotnetslash.net From amk at amk.ca Tue Oct 28 14:31:13 2003 From: amk at amk.ca (amk@amk.ca) Date: Tue Oct 28 14:32:46 2003 Subject: [Distutils] Testing the Distutils Message-ID: <20031028193113.GA2665@rogue.amk.ca> I've created a Wiki page for collecting ideas about a Distutils test suite at http://www.python.org/cgi-bin/moinmoin/DistutilsTesting . Please edit it with your own suggestions and ideas. --amk From cjw at sympatico.ca Wed Oct 29 14:36:11 2003 From: cjw at sympatico.ca (Colin J. Williams) Date: Wed Oct 29 14:37:03 2003 Subject: [Distutils] Preparation of a pure python package for the Windows installer Message-ID: <3FA016AB.8020308@sympatico.ca> I get the impression from the documentation that it should be possible to use distutils to distribute a pure Python package in a form acceptable by the Windows installer. Is this correct? If so, I would appreciate advice on where I've gone astray in the script below. If I enter this line: C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py sdist the expected zip file is produced. in C:\Program Files\Python23\Lib\site-packages\PyMatrix\dist Colin W. ------------------------------------------------------------------------ C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py bdist_wininst running bdist_wininst running build installing to build\bdist.win32\wininst running install_data creating build creating build\bdist.win32 creating build\bdist.win32\wininst creating build\bdist.win32\wininst\DATA creating build\bdist.win32\wininst\DATA\Docs error: can't copy 'copy.html': doesn't exist or not a regular file C:\Program Files\Python23\Lib\site-packages\PyMatrix> From theller at python.net Wed Oct 29 15:08:22 2003 From: theller at python.net (Thomas Heller) Date: Wed Oct 29 15:08:36 2003 Subject: [Distutils] Preparation of a pure python package for the Windows installer In-Reply-To: <3FA016AB.8020308@sympatico.ca> (Colin J. Williams's message of "Wed, 29 Oct 2003 14:36:11 -0500") References: <3FA016AB.8020308@sympatico.ca> Message-ID: "Colin J. Williams" writes: > I get the impression from the documentation that it should be possible > to use distutils to distribute a pure Python package in a form > acceptable by the Windows installer. > > Is this correct? Yes. > If so, I would appreciate advice on where I've gone astray in the > script below. > > If I enter this line: > C:\Program Files\Python23\Lib\site-packages\PyMatrix>python > setup.py sdist > the expected zip file is produced. in > C:\Program Files\Python23\Lib\site-packages\PyMatrix\dist > > Colin W. > ------------------------------------------------------------------------ > > C:\Program Files\Python23\Lib\site-packages\PyMatrix>python setup.py > bdist_wininst > running bdist_wininst > running build > installing to build\bdist.win32\wininst > running install_data > creating build > creating build\bdist.win32 > creating build\bdist.win32\wininst > creating build\bdist.win32\wininst\DATA > creating build\bdist.win32\wininst\DATA\Docs > error: can't copy 'copy.html': doesn't exist or not a regular file > > C:\Program Files\Python23\Lib\site-packages\PyMatrix> Colin, can you post your setup.py script to see what's wrong? Thomas From aegisk at vrac.iastate.edu Wed Oct 29 16:17:55 2003 From: aegisk at vrac.iastate.edu (Chad Austin) Date: Wed Oct 29 16:18:15 2003 Subject: [Distutils] [Fwd: Re: [scons-devel] specifying python interpreter for #! in scons.py?] Message-ID: <3FA02E83.40000@vrac.iastate.edu> I'm not on the distutils-sig mailing list, so please CC me on any responses. Is there a way to specify the command used to load Python in a script installed via distutils? Distutils automatically adds #! to the top of installed scripts, where is an absolute path to the Python interpreter used to execute setup.py. I'd like to be able to specify the #! command because I use a single installation of SCons on platforms with the 'python' command in different locations. Is this possible? Thanks much! Chad -------- Original Message -------- Subject: Re: [scons-devel] specifying python interpreter for #! in scons.py? Date: Wed, 29 Oct 2003 15:47:06 -0500 From: Stefan Seefeld To: scons-devel@lists.sourceforge.net References: <3FA024D6.6080805@vrac.iastate.edu> Chad Austin wrote: > Is there a way, using distutils, to specify the command used to load > Python in scons.py? We would like a single SCons installation on a > networked filesystem so that all machines (Linux and SGI) can use it. > However, Python is available in /usr/bin on Linux and /usr/freeware/bin > on IRIX. On install, distutils adds #! to the top of scons.py, > where is the version of Python used to install. Anyone know of > a way to tell distutils to put "#!/usr/bin/env python" at the top of the > file? there is none (the relevant distutils command is 'build_scripts', in case you want to have a look). I'd suggest you address this issue on the distutils ML. Specifically, I'd prefer distutils to (optionally) not touch the first line, and thus giving the user the chance to put whatever he wants there. That'd offer even more flexibility than the default '#!/usr/bin/env python'... Stefan ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ scons-devel mailing list scons-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/scons-devel From sunking77 at hotmail.com Fri Oct 31 12:28:17 2003 From: sunking77 at hotmail.com (Ray) Date: Fri Oct 31 12:28:20 2003 Subject: [Distutils] bdist_wininst--error's Message-ID: <000001c39fd4$5f388a90$041ad20c@computer> When I use bdist_wininst I get a bunch of 'Module not found' error messages, but it does seem to work, it does give an installer program for "My script"(name of program). But the installer doesn't install the program it only installs a read me file and an uninstall option in the Python22\ directory, when I run the installer it states the install Directory as 'Python22\libs\site-packages', but when go to that directory it's not there .Where did it go??? -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20031031/8826c012/attachment.html From amk at amk.ca Fri Oct 31 14:44:35 2003 From: amk at amk.ca (amk@amk.ca) Date: Fri Oct 31 14:44:42 2003 Subject: [Distutils] [Fwd: Re: [scons-devel] specifying python interpreter for #! in scons.py?] In-Reply-To: <3FA02E83.40000@vrac.iastate.edu> References: <3FA02E83.40000@vrac.iastate.edu> Message-ID: <20031031194435.GA18641@rogue.amk.ca> On Wed, Oct 29, 2003 at 03:17:55PM -0600, Chad Austin wrote: > Is there a way to specify the command used to load Python in a script > installed via distutils? Distutils automatically adds #! to the No, not at the moment. It's not a bad idea, though; look at distutils/commands/build_scripts.py for the code to change. --amk From sunking77 at hotmail.com Fri Oct 31 16:18:05 2003 From: sunking77 at hotmail.com (Ray) Date: Fri Oct 31 16:18:00 2003 Subject: [Distutils] invalid syntax??? Message-ID: <000001c39ff4$796f4dc0$041ad20c@computer> Python setup.py py2exe Invalid syntax is the error message I get when I type this in. Which is nuts cause that is the exact syntax I should be using according the Py2exe website. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20031031/0ab213ce/attachment.html From sunking77 at hotmail.com Fri Oct 31 16:18:06 2003 From: sunking77 at hotmail.com (Ray) Date: Fri Oct 31 16:18:02 2003 Subject: [Distutils] py2exe correct syntax for changing icon Message-ID: <000501c39ff4$79f28780$041ad20c@computer> Using the -icon option to change the icon for my App but I keep getting 'syntax error messages Example: python setup.py py2exe -icon desktop\icons\EXE icon.ico Do I use the python shell or the DOS command line? What is the proper syntax I should be using -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/distutils-sig/attachments/20031031/4e84bbd2/attachment.html