Distutils-SIG April 2001

distutils-sig@python.org

23 participants
33 discussions

RE: [Distutils] using distutils for an application
by Philippe FREMY 26 Apr '01

26 Apr '01

> > > > Distutils is very module centric. It is very efficient to > install a module > > but doesn't answer the needs of installing applications. > > It wasn't designed for packaging applications, > Reading the SIG intruduction: "The goal of the Distribution Utilities (`distutils') is to make building, distributing, and installing Python modules, extensions, and applications painless and standardized." I see the word "applications" there :-) > > The problems I had are: > > - where to install the program data ? > > distutils has a command install_data for this which you may want > to use. I didn't see it or was unable to use it. Is it really possible to install data and then load them at runtime without any problem ? > > - how to make the program visible to the underlying os (Menu, etc) ? > > On Windows, you would add a Menu entry... I'm not sure how > this is done and whether distutils has any support for this. > On Unix, there is no standard method for this. Not sure > about Macs. This is exactly the point I would like to make. There is no standard method _yet_. But I think it should be worked out. > but it should > be possible to tweak the implementation according to your needs > by subclassing distutils commands. This should not be a tweak every different program has to rewrite. A handwritten unstandard installation method is not a good idea. There are more and more applications developed with python today, especially since there are more graphical toolkits available : PyQt, PyGtk, PyGnome, PyWxWindow, Tkinter, etc. A standard way of distributing a python application is really needed. There is not that much to define, given how much has already been done with DistUtils: - define where to install runtime data and how to load it - define perhaps how to store and load user data - provide a way to install the program in the standard menu system: -> gnome, kde, windows, mac, ... On unix, this could be configurable and left up to the guy installing the program to decide for what environment he want a menu entry. What do you think about this ? regards, Philippe

2 1

docs and samples
by Pete Shinners 24 Apr '01

24 Apr '01

hello distutils. i've got my sizeable package that distutils is now handling really well. i've got some questions on how to best cleanup some loose ends. first, the package comes with a good supply of documentation and example code. this is really useful and i'd like to do my best to guarantee anyone who installs also has these on hand. currently these files are all in my MANIFEST template, so they are included with the "sdist" archives. i haven't put them into my "install_data" yet, because i'm not sure where i should put them. i've seen pyopengl just puts all this into it's installed "site-packages" directory, which hasn't bothered me really, but i don't know if all users will be able to find it there. has anyone figured out a standard way to do this, perhaps distutils should also have a "install_docs" command which can put things in the proper place? in my specific case the docs are in HTML, and the sample code requires the use of many binary data files. i'm just not sure what to do with these?

1 0

using distutils for an application
by Philippe FREMY 24 Apr '01

24 Apr '01

Hi, I have developped an application with Python and PyQt (klotski, see http://klotski.berlios.de/klotski/) and was faced with the problem of distribution. I was told to look at distutils but this wasn't the answer to my problems. Distutils is very module centric. It is very efficient to install a module but doesn't answer the needs of installing applications. The problems I had are: - where to install the program data ? - how to start the program ? Use a loader ? Tell people to run python klotski.py ? - how to make the program visible to the underlying os (Menu, etc) ? - how to load the data that have been installed (find their location at runtime) ? I solved all this using a shell script loader and a Makefile to install everything under /usr/share for Unix. For windows, I just left everything in the same directory. I wonder if you have advices regarding this kind of problem and if they are going to be adressed by distutils or if it is considered to be too much os-specific. regards, Philippe ps: I am not subscribed, so please cc me any answer.

2 1

building wxpython with msvc
by Terrel Shumway 23 Apr '01

23 Apr '01

Building wxPython in an unusual environment I discovered that MS link.exe uses the environment variable TMP for its temporary files. unusual environment: \ is not writable by current user os.env["TMP"] is not set result: link.exe fails: "\lnk2 does not exist" Solution: before calling link.exe, make sure TMP is set and points to a writable directory. This fix should probably go into distutils.

1 0

Installers for Numeric
by Paul F. Dubois 23 Apr '01

23 Apr '01

Dear Nummies, If you picked up the source installer for 20.0.0b2 in the first hour after I released it, it will die when building "kinds". Since you probably don't care, everything else will have been done by then. I have fixed both the .tar.gz and .zip source distributions now. This egregious error gives me the chance to say that I haven't the slightest idea whether the rpm and source rpm work. I just made 'em with Distutils. You rpm freaks out there will have to check it out and if it needs fixing, fix it. But we get so many people asking for those and for the Windows installers that I thought it worth a shot. Distutils burbled along pleasantly while making them, anyway. I did try the Windows installers and although they seem to work the "uninstall" didn't work for me. I have no clue if that is because that command isn't expected to work yet or not. Well informed, aren't I? Can you do better? Please do. == Paul

3 5

Change in build_ext breaks code
by M.-A. Lemburg 18 Apr '01

18 Apr '01

A recent change (fix) in build_ext.py breaks code which wants to override .finalize_options(): revision 1.68.2.1 date: 2001/03/31 16:09:32; author: moshez; state: Exp; lines: +20 -2 - #233253 - distutils/command/build_ext.py - the --define and --undef options didn't work, whether specified on the command-line or in setup.cfg. - distutils/command/build_ext.py - make docstrings raw - #128930 - distutils/command/build_ext.py - split rpath argument Suggested by AMK, but had to be massaged a bit from the cvs diff The proper thing to do would be to test .define and .undefine for strings (which are set by the command-line args) before tweaking them into tuples... -- Marc-Andre Lemburg ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Pages: http://www.lemburg.com/python/

1 0

Problem with build_clib building PIL
by Nicolas Chauvat 16 Apr '01

16 Apr '01

Hi folks, I downloaded the latest PIL source tarball from pythonware.com, copied the pil_setup.py example available from the latest Distutil (1.0.1) to Imaging-1.1.1/setup.py, cd'd to that directory and ran 'python setup.py sdist', only to see it fail: [nico@mybox Imaging-1.1.1]$ python setup.py sdist running sdist warning: sdist: manifest template 'MANIFEST.in' does not exist (using default file list) Traceback (innermost last): File "setup.py", line 181, in ? libraries = optional_libs)] File "/usr/lib/python1.5/site-packages/distutils/core.py", line 138, in setup dist.run_commands() File "/usr/lib/python1.5/site-packages/distutils/dist.py", line 829, in run_commands self.run_command(cmd) File "/usr/lib/python1.5/site-packages/distutils/dist.py", line 849, in run_command cmd_obj.run() File "/usr/lib/python1.5/site-packages/distutils/command/sdist.py", line 143, in run self.get_file_list() File "/usr/lib/python1.5/site-packages/distutils/command/sdist.py", line 242, in get_file_list self.add_defaults() File "/usr/lib/python1.5/site-packages/distutils/command/sdist.py", line 319, in add_defaults self.filelist.extend(build_clib.get_source_files()) File "/usr/lib/python1.5/site-packages/distutils/cmd.py", line 107, in __getattr__ raise AttributeError, attr AttributeError: get_source_files [nico@mybox Imaging-1.1.1]$ I checked the file .../distutils/command/build_clib.py and it doesn't have the missing get_source_files() method, whereas build_py.py and build_ext.py have it. I don't have time to figure out what the actual problem is and to come up with a fix in case it'd be needed, I hope someone will... [please cc me as I'm not on the list] -- Nicolas Chauvat http://www.logilab.com - "Mais où est donc Ornicar ?" - LOGILAB, Paris (France)

1 0

Re: Distutil BUG in RC1 !!
by Guido van Rossum 14 Apr '01

14 Apr '01

> i'm guessing this is kind of urgent, i just found a bug in > the distutils that came with my recently downloaded Python2.1C1 > i installed on windows, using the win-installer for 2.1c1 > > here's the quick and dirty details... > > in the file "lib/distutils/archive-util.py" line 103, it creates > a ZIP archive with the following command... > > ZipFile(zip_filename, "wb", compression=zipfile.ZIP_DEFLATED) > > > the problem here is the file mode, "wb". the zipfile.py that comes > with 2.1c1 only allows the following file modes; "r", "w", or "a". > this can be seen at line 166 in "lib/zipfile.py" > > modeDict = {'r' : 'rb', 'w': 'wb', 'a' : 'r+b'} > self.fp = open(file, modeDict[mode]) > > > > personally, i would think it better to make the zipfile smart enough > to handle "wb" as a mode, but it certainly does not. anyways, the > "sdist" command fails when building a zipfile because of this. > > > please, someone tell me this won't be found when the final Python-2.1 > is released in a few days. i'll mail out a full scale assault-style > warning if there's still no news by the 16th. but i figure it can be > handled most quickly and cleanly right here and now in disutils-sig Thanks for reporting. Fixing modeDict in zipfile.py isn't enough, because there are other places where it relies on the key being one of 'r', 'w', or 'a'. So I propose this fix to archive-util.py: *** archive_util.py 2000/09/26 02:13:49 1.9 --- archive_util.py 2001/04/14 16:15:14 *************** *** 100,106 **** z.write(path, path) if not dry_run: ! z = zipfile.ZipFile(zip_filename, "wb", compression=zipfile.ZIP_DEFLATED) os.path.walk(base_dir, visit, z) --- 100,106 ---- z.write(path, path) if not dry_run: ! z = zipfile.ZipFile(zip_filename, "w", compression=zipfile.ZIP_DEFLATED) os.path.walk(base_dir, visit, z) I will check this in now. I can't test it though, so please let me know whether this solves the problem. --Guido van Rossum (home page: http://www.python.org/~guido/)

1 0

Distutil BUG in RC1 !!
by Pete Shinners 13 Apr '01

13 Apr '01

i'm guessing this is kind of urgent, i just found a bug in the distutils that came with my recently downloaded Python2.1C1 i installed on windows, using the win-installer for 2.1c1 here's the quick and dirty details... in the file "lib/distutils/archive-util.py" line 103, it creates a ZIP archive with the following command... ZipFile(zip_filename, "wb", compression=zipfile.ZIP_DEFLATED) the problem here is the file mode, "wb". the zipfile.py that comes with 2.1c1 only allows the following file modes; "r", "w", or "a". this can be seen at line 166 in "lib/zipfile.py" modeDict = {'r' : 'rb', 'w': 'wb', 'a' : 'r+b'} self.fp = open(file, modeDict[mode]) personally, i would think it better to make the zipfile smart enough to handle "wb" as a mode, but it certainly does not. anyways, the "sdist" command fails when building a zipfile because of this. please, someone tell me this won't be found when the final Python-2.1 is released in a few days. i'll mail out a full scale assault-style warning if there's still no news by the 16th. but i figure it can be handled most quickly and cleanly right here and now in disutils-sig

1 0

Solaris and HP binary commands
by Mark W. Alexander 11 Apr '01

11 Apr '01

Thanks to Andrew's work on PEP 241, I finally got motivated to revisit bdist commands for Solaris pkgtool and HP's SD-UX. Attached are three files bdist_packager.py provides an abstract base class for bdist commands. It provides easy access to all the PEP 241 metadata fields, plus "revision" for the package revision and installation scripts for preinstall, postinstall preremove, and postremove. That covers the base characteristics of all the package managers that I'm familiar with. If anyone can think of any others, let me know, otherwise additional extensions would be implemented in the specific packager's commands. I would, however, discourage _requiring_ any additional fields. It would be nice if by simply supplying the PEP241 metadata under the [bdist_packager] section all subclassed packagers worked with no further effort. It also has rudimentary relocation support by including a --no-autorelocate option. The bdist_packager is also where I see creating seperate binary packages for sub-packages supported. My need for that is much less than my desire for it right now, so I didn't give it much thought as I wrote it. I'd be delighted to hear any comments and suggestions on how to approach sub-packaging, though. The bdist_pktool command provides support for the Solaris pkgadd and pkgrm commands. In most cases, no additional options beyond the PEP 241 options are required. An exception is if the package name is >9 characters, a --pkg-abrev option is required because that's all pkgtool will handle. It makes listing the packages on the system a pain, but the actual package files produced do match name-version-revision-pyvers.pkg format. By default, bdist_pkgtool provides request, postinstall, preremove, and postremove scripts that will properly relocate modules to the site-packages directory and recompile all .py modules on the target machine. An author can provide a custom request script and either have it auto-relocate by merging the scripts, or inhibit auto-relocation with --no-autorelocate. The bdist_sdux command provides the same functionality as the pkgtool command, except the resulting packages cannot auto-relocate. Instead, a checkinstall script is included by default that determines of the target machines python installation matches that of the creating machine. If not, it bails out and provides the installer with the correct version of the swinstall command to place it in the proper directory. I have tested both these with some local packages, and with Marc-Andre's Egenix-mx-base. They work as long as the result is a single directory tree under site-packages. If anyone has modules that require multiple site-packages directories, or install in multiple directories somewhere else, I'd appreciate a note telling me where I can get them for testing. (I can almost gaurantee they won't handle header files properly.) Finally, I have some questions regarding some things I don't think I totally grasp. First, is there a Distutils method for determining the modules root directory under site-packages? I hacked it by grabbing distribution.packages[0], but that's probably easily broken. Second, in order to handle setup.cfg options in the subclassed commands, I had to scan self.distribution.get_option_dict('bdist_packager') and copy options to the instance during initialize_options. Somehow, that just feels wrong. Shouldn't they be inherited somehow? There's still some stuff to do. I'd like to have seperate classes for doc files, like rpm does, but I also want as much of the setup configuration as possible to be in the binary_packager class so it doesn't have to be replicated by every possible packager command. Any ideas on a "generic" way to specify file "classes", like headers, docs, etc. please let me know (including pointers to discussions already had....I know there where some, but I couldn't readily find them). I think the concept is probably best handled in the same way as producing multiple packages; so if you specify doc files, a seperate "doc" package would be produced. How does that sound? Anyway, if you've got Solaris and HP access, please give them a workout and let me know how it goes. (You MUST have the PEP 241 patches, or you won't be able to get to any of those options.) Mark Alexander mwa(a)gate.net

3 4

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

Distutils-SIG April 2001