Hi all --
at long last, I have fixed two problems that a couple people noticed a
while ago:
* I folded in Amos Latteier's NT patches almost verbatim -- just
changed an `os.path.sep == "/"' to `os.name == "posix"' and added
some comments bitching about the inadequacy of the current library
installation model (I think this is Python's fault, but for now
Distutils is slavishly aping the situation in Python 1.5.x)
* I fixed the problem whereby running "setup.py install" without
doing anything else caused a crash (because 'build' hadn't yet
been run). Now, the 'install' command automatically runs 'build'
before doing anything; to make this bearable, I added a 'have_run'
dictionary to the Distribution class to keep track of which commands
have been run. So now not only are command classes singletons,
but their 'run' method can only be invoked once -- both restrictions
enforced by Distribution.
The code is checked into CVS, or you can download a snapshot at
http://www.python.org/sigs/distutils-sig/distutils-19990607.tar.gz
Hope someone (Amos?) can try the new version under NT. Any takers for
Mac OS?
BTW, all parties involved in the Great "Where Do We Install Stuff?"
Debate should take a good, hard look at the 'set_final_options()' method
of the Install class in distutils/install.py; this is where all the
policy decisions about where to install files are made. Currently it
apes the Python 1.5 situation as closely as I could figure it out.
Obviously, this is subject to change -- I just don't know to *what* it
will change!
Greg
--
Greg Ward - software developer gward(a)cnri.reston.va.us
Corporation for National Research Initiatives
1895 Preston White Drive voice: +1-703-620-8990
Reston, Virginia, USA 20191-5434 fax: +1-703-620-0913
Hi all,
I've been aware that the distutils sig has been simmerring away, but
until recently it has not been directly relevant to what I do.
I like the look of the proposed api, but have one question. Will this
support an installed system that has multiple versions of the same
package installed simultaneously? If not, then this would seem to be a
significant limitation, especially when dependencies between packages
are considered.
Assuming it does, then how will this be achieved? I am presently
managing this with a messy arrangement of symlinks. A package is
installed with its version number in it's name, and a separate
directory is created for an application with links from the
unversioned package name to the versioned one. Then I just set the
pythonpath to this directory.
A sample of what the directory looks like is shown below.
I'm sure there is a better solution that this, and I'm not sure that
this would work under windows anyway (does windows have symlinks?).
So, has this SIG considered such versioning issues yet?
Cheers,
Tim
--------------------------------------------------------------
Tim Docker timd(a)macquarie.com.au
Quantative Applications Division
Macquarie Bank
--------------------------------------------------------------
qad16:qad $ ls -l lib/python/
total 110
drwxr-xr-x 2 mts mts 512 Nov 11 11:23 1.1
-r--r----- 1 root mts 45172 Sep 1 1998 cdrmodule_0_7_1.so
drwxr-xr-x 2 mts mts 512 Sep 1 1998 chart_1_1
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Fnorb_0_7_1
dr-xr-x--- 3 mts mts 512 Nov 11 11:21 Fnorb_0_8
drwxr-xr-x 3 mts mts 1536 Mar 3 12:45 mts_1_1
dr-xr-x--- 7 mts mts 512 Nov 11 11:22 OpenGL_1_5_1
dr-xr-x--- 2 mts mts 1024 Nov 11 11:23 PIL_0_3
drwxr-xr-x 3 mts mts 512 Sep 1 1998 Pmw_0_7
dr-xr-x--- 2 mts mts 512 Nov 11 11:21 v3d_1_1
qad16:qad $ ls -l lib/python/1.1
total 30
lrwxrwxrwx 1 root other 29 Apr 10 10:43 _glumodule.so -> ../OpenGL_1_5_1/_glumodule.so
lrwxrwxrwx 1 root other 30 Apr 10 10:43 _glutmodule.so -> ../OpenGL_1_5_1/_glutmodule.so
lrwxrwxrwx 1 root other 22 Apr 10 10:43 _imaging.so -> ../PIL_0_3/_imaging.so
lrwxrwxrwx 1 root other 36 Apr 10 10:43 _opengl_nummodule.so -> ../OpenGL_1_5_1/_opengl_nummodule.so
lrwxrwxrwx 1 root other 27 Apr 10 10:43 _tkinter.so -> ../OpenGL_1_5_1/_tkinter.so
lrwxrwxrwx 1 mts mts 21 Apr 10 10:43 cdrmodule.so -> ../cdrmodule_0_7_1.so
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 chart -> ../chart_1_1
lrwxrwxrwx 1 root other 12 Apr 10 10:43 Fnorb -> ../Fnorb_0_8
lrwxrwxrwx 1 mts mts 12 Apr 10 10:43 mts -> ../mts_1_1
lrwxrwxrwx 1 root other 15 Apr 10 10:43 OpenGL -> ../OpenGL_1_5_1
lrwxrwxrwx 1 root other 33 Apr 10 10:43 opengltrmodule.so -> ../OpenGL_1_5_1/opengltrmodule.so
lrwxrwxrwx 1 root other 33 Apr 10 10:43 openglutil_num.so -> ../OpenGL_1_5_1/openglutil_num.so
lrwxrwxrwx 1 root other 10 Apr 10 10:43 PIL -> ../PIL_0_3
lrwxrwxrwx 1 mts mts 10 Apr 10 10:43 Pmw -> ../Pmw_0_7
lrwxrwxrwx 1 root other 10 Apr 10 10:43 v3d -> ../v3d_1_1
Hi All,
I'm wondering what the state of play is with the following branches:
reinout-scripts
gary-4-include-site-packages
What more needs to happen for these to get merged to trunk and a release
made?
cheers,
Chris
Hi!
I want to know how to keep a compiled package to its smallest size? In
other words instead of compiling all Python code, keep it to only what the
modules use.
BT
In general it is possible for an installation to make certain system changes
other than the record of files written during an installation (for example,
under Windows, there may be distribution-specific Windows registry updates).
There seems to be no hook that's called when a distribution is removed, which
would allow distribution-specific cleanup code to be called (e.g. to undo
Windows registry changes).
Such a hook should be provided, and I've created a ticket for this:
http://bugs.python.org/issue12416
I believe there should be a pre- and a post- hook, just as there is for
commands. Éric has suggested getting opinions from the mailing list, so what do
you all think about this?
Regards,
Vinay Sajip
Hi Jim,
Have you had any dealings with Enthought's Python Distribution:
https://www.enthought.com/products/epd.php
It looks like a useful tool, providing pre-compiled and compatible
versions of a lot of the numeric and scientific libraries that can be a
total PITA to get installed and working with each other...
They also have their own installer tool, enpkg, which, from what I can
tell behaves a lot like easy_install.
I wonder what your thoughts are about getting buildout and EPD to play
nicely with each other?
cheers,
Chris
--
Simplistix - Content Management, Batch Processing & Python Consulting
- http://www.simplistix.co.uk
Hi,
I've got a Distribute question: We bundle a library in our application. The
library is already py3k compatible but we need to use 2to3 for our code. Is
there a way to tell Distribute to skip a directory? Or, alternatively, to
feed it a list of to run 2to3 on directly. I looked at the relevant code (in
build_py) but I can't seem to get it. How does Distribute know which files
have changed? Perhaps we could "trick" it into thinking that directory
hasn't changed so that it wouldn't run 2to3 on it. If this is not possible
at all, I'd be willing to code it for Distribute (provided someone gives me
some pointers).
Thanks!
--
Vladimir Perić
I've a project which needs to install different data files depending on what
platform the project is being installed on - e.g. win32, linux2, darwin. Using
packaging setup.cfg, how can I indicate different files for different platforms,
as well as some common files for all platforms? It's easy enough to do with
setup.py, of course.
It doesn't seem possible to use project-specific Python files to do this (via
setup_hooks, for example), as when pysetup3 runs, the project directory is not
in sys.path, so you can't import anything from e.g. files adjacent to setup.cfg.
Although my current need is for data files, there might be situations where
different packages need installing for different platforms (e.g. having shim or
adapter functionality).
What's the official packaging solution for this?
Regards,
Vinay Sajip
I'm testing a branch of Python which provides out-of-the-box ability to create
virtual enviroments à la virtualenv, and as part of that testing I have to
install Distribute in newly created environments a lot. Though normally running
2to3 as part of the Distribute installation is not a big deal, for this testing
I'm doing, it does slow things down a little.
While waiting for some tests to finish, I thought I might as well look into
whether Distribute could be made to run on 2.x and 3.x from a single code base,
thereby avoiding the 2to3 step.
I've made an attempt, and things seem to have gone reasonably smoothly: the
conversion is done and all unit tests pass on 2.7, 3.2, 3.3 (my branch).
The converted Distribute is at
https://bitbucket.org/vinay.sajip/distribute3
In case any of you are interested at taking a look, I'd welcome any feedback you
have.
Regards,
Vinay Sajip
