> >
> > 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
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?
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.
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.
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
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/
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)
> 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/)
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 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
