Mailman 3 January 2001 - Distutils-SIG

RE: [Distutils] bdist_wininst
by Moore, Paul Jan. 20, 2001

Jan. 20, 2001

From: Thomas Heller [mailto:thomas.heller@ion-tof.com] > > At the absolute minimum, the install target should allow > > specifying an alternative target. And the wininst installer > > needs to offer the user a choice of install directory. > > > wininst once had such an option. I removed it because of > Greg's suggestion: > > The developer can override it by using the 'extra_path' > option to the setup function. The developer can, but the end user who is installing the package can't. (Can he? I haven't actually looked, but this is how I read the messages...) Paul

2 1

py2exe - convert python scripts into exe files (windows)
by Thomas Heller Jan. 19, 2001

Jan. 19, 2001

I've created a distutils extension to convert python scripts into standalone windows executable files. You end up with an exe-file as well as pythonxx.dll plus some .pyd's. This is more or less a rewrite of Gordon's installer project. Homepage: http://starship.python.net/crew/theller/py2exe/ Compatibility: Python 1.5 or later. License: BSD Regards, Thomas Heller

2 1

RE: [Distutils] bdist_wininst
by Moore, Paul Jan. 19, 2001

Jan. 19, 2001

From: Pete Shinners [mailto:pete@visionart.com] > > > * no documentation files are installed -- is there a way to get > > those installed somewhere > > mmm, a python standard location for documentation would be a > big help. all my docs are currently in HTML, but i'm sure many > people are using a variety of formats. nonetheless, if python > had a standard format/location for documentation i think the > all users would benefit. perhaps distutils laying out some sort > of resonable standard on its own would be enough to get the > whole community to adopt it? > (of course, some documentation browsing tools in python would > be a nice followup) Agreed, this would be good. It's not a distutils issue as such, but if the distutils package offered a standard for *where* documentation went, it might help promote some discussion and/or action on defining what *form* documentation should take, etc. Perl currently has a big win here, with POD. Like it or loathe it, it's guaranteed to work for pretty much everything - a bit like man on Unix... > > * the installer install directly into \Python20 -- shouldn't > > it install to \Python20\Lib ? What's the standard here on > > Windows ? > > distutils on windows always installs to this directory. bdist or > otherwise. i don't see any need for change? I asked this once before. I gather that it's a Guido-mandated standard. I dislike it intensely, however. I think that user-installed modules should be segregated from standard ones. The obvious place is <PythonDir>\Lib\site-packages. But that needs site.py to change to handle this directory on Windows, as well as on Unix (I see no logic to why it doesn't already). At the very least, <PythonDir>\Local would be better, with distutils creating the directory, and probably adding a Local.pth, if it doesn't already exist. I hate this default so much that I *always* download sources, and do python setup.py build, and then install by hand. This is stupid. At the absolute minimum, the install target should allow specifying an alternative target. And the wininst installer needs to offer the user a choice of install directory. <end rant> Paul.

3 2

Re: Distutils-SIG digest, Vol 1 #427 - 5 msgs
by Michel Van den Bergh Jan. 19, 2001

Jan. 19, 2001

> * the installer install directly into \Python20 -- shouldn't > it install to \Python20\Lib ? What's the standard here on Windows ? Come to think of it. Why not allowing to install anywhere in the file system, like bdist_rpm does? With this trivial change you could use bdist_wininst as an installer for python applications, not just extensions. Michel

1 0

bdist_wininst
by M.-A. Lemburg Jan. 18, 2001

Jan. 18, 2001

I've just tried to create a wininst based version of my packages. The installer works great except for a few nits: * the text box showing the description could be wider * no documentation files are installed -- is there a way to get those installed somewhere * the installer install directly into \Python20 -- shouldn't it install to \Python20\Lib ? What's the standard here on Windows ? * the installer doesn't register itself in the Windows Software registry -- an uninstall is not possible (this would be *very* nice to have) Any hints ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

3 6

Re: Detecting install time
by Andrew Kuchling Jan. 16, 2001

Jan. 16, 2001

[CC'ing to the distutils-sig] On Mon, Jan 15, 2001 at 10:47:32PM -0500, Guido van Rossum wrote: >> For PEP 229, the setup.py script needs to figure out if it's running >> from the build directory, because then distutils.sysconfig needs to > >You could check for the presence of config.status -- that file is not >installed. This isn't a check suitable for inclusion in distutils.sysconfig, though, because it's so liable to being fooled (consider a Distutils-packaged module that comes with a configure script to build some library). Right now I'm using a hacked version of sysconfig with several patches like this: @@ -120,12 +121,16 @@ def get_config_h_filename(): """Return full pathname of installed config.h file.""" inc_dir = get_python_inc(plat_specific=1) + # XXX + if 1: inc_dir = '.' return os.path.join(inc_dir, "config.h") One hackish approach would be to add a assume_build_directories() to distutils.sysconfig, a little back door to be used by the setup.py script that comes with Python, so the above would become 'if build_time_flag: ...'. Anyone have a cleaner idea? --amk

1 0

FORTRAN extension modules
by John J. Lee Jan. 16, 2001

Jan. 16, 2001

Has anyone added any FORTRAN support since the version of Distutils that came with python 2.0? I tried compiling Multipack with Distutils (after setting up the source with modified versions of the Makefile and setmodules.py from the Multipack distribution) by subclassing from UnixCCompiler, but of course that only works if you do it in two steps: ./setup.py build_clib -c unixf ./setup.py build_ext where unixf is my added FORTRAN compiler. I suppose the right thing would be to put it in CCompiler itself, so that all its subclasses would be capable of compiling FORTRAN too (with appropriate modifications)? I suppose the same would be true of, eg Pascal too. Maybe the class needs renaming too... John

1 1

Re: [Python-Dev] Where's Greg Ward ?
by M.-A. Lemburg Jan. 16, 2001

Jan. 16, 2001

[CCed to distutils, since it matters there] Tim Peters wrote: > > [MAL] > > He seems to be offline and the people on the distutils list have > > some patches and other things which would be nice to have in > > distutils for 2.1. > > Greg's somewhere near the end of the process of moving from Virginia to > Canada; I expect he'll become visible again Real Soon. Great :) > > I suppose we could simply check in the patches, but we still want > > to get his OK on things before applying patches to the distutils > > tree. > > The distutils SIG could elect a Shadow Dictator in his place; if everyone > agrees to vote for Andrew, you save the effort of counting votes <wink>. Ok, let's agree to vote for Andrew :) Andrew, is that OK with you ? -- Marc-Andre Lemburg ______________________________________________________________________ Company: http://www.egenix.com/ Consulting: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/

4 6

Re: [Distutils] Problems with distutils and multiple developers under sol2 (unix)
by Berthold Höllmann Jan. 15, 2001

Jan. 15, 2001

hoel(a)germanlloyd.org (Berthold Höllmann) writes: > Hello, > > We are developing a set of inhouse applications using Python. To put > our Python code to the appropriate places under different Operating > systems, we use distutils. But we have a problem with the unix > permissons. User A develops package a.py and installs it using > distutils. Later user B finds an enhancement/bug, corrects package > a.py. But when he tries to install this using distutils he always gets > an error message when distutils try to set the file permissions this > fails because user A is still owner of the copied file after the > copiing process. I think, distutils should first delete an old file, > before trying to install/copy a new one. Can anyone see any problem > with this aproach? Or should the "chmod" command simly included in a > "try:" block to ignore errors that might occur? As a followup, here my solution of the problem for distutils 1.0.1: in the file "file_util.py" I inserted the if os.path.isfile(dst): os.remove(dst) as new line 40 in the function "_copy_file_contents". This seems to work at least for us. I hope, that something like that can make its way into the next distutils versions. Thanks Berthold -- email: hoel(a)GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer.

1 0

Problems with distutils and multiple developers under sol2 (unix)
by Berthold Höllmann Jan. 15, 2001

Jan. 15, 2001

Hello, We are developing a set of inhouse applications using Python. To put our Python code to the appropriate places under different Operating systems, we use distutils. But we have a problem with the unix permissons. User A develops package a.py and installs it using distutils. Later user B finds an enhancement/bug, corrects package a.py. But when he tries to install this using distutils he always gets an error message when distutils try to set the file permissions this fails because user A is still owner of the copied file after the copiing process. I think, distutils should first delete an old file, before trying to install/copy a new one. Can anyone see any problem with this aproach? Or should the "chmod" command simly included in a "try:" block to ignore errors that might occur? Cheers Berthold -- email: hoel(a)GermanLloyd.org ) tel. : +49 (40) 3 61 49 - 73 74 ( C[_] These opinions might be mine, but never those of my employer.

1 0