Generally I'm looking at distutils to see if it can help me simplify
the installation of some of the JPython modules I have created.
A JPython modules could typically consists of:
- .py files
- .jar file or .class files
- .dll files
Lets first assume that all these files have been compiled and built
in some traditional way. In order to get started with distutils, I
will avoid any attempt to compile any of the C/C++ source at the
target machine. So this is windows only, at least to begin with.
My primary target user is a java/jpython developer.
Copying the .py files works like a dream.
For .jar files, the situation get more complicated. A jar file could:
a) be copied to an well-known directory f.ex. a subdir to sys.prefix.
The JPython startup script would then have to be changed. I.e.
inserting the new .jar in the -classpath or /cp option to the
b) If using Sun-JDK, the jar could be copied to the "$java.ext.dir"
directory in the JDK/JRE installation.
c) If using MS-jview, the jar could be extracted into
"$java.home\Lib" or "$java.home\TrustLib" directory.
java.home is narmmaly something like "c:\windows\Java"
d) Some other directory, leaving it entirely up to the user to fiddle
with startup scripts and CLASSPATH environment variables.
Other JVMs could possible have different default places where class
files are located. Even if distutils will support all methods, I think
the user must be queried which strategy she want to use.
For .dll files, the situation get similar. A dll file could:
a) be copied to one of the directories on the current PATH (only
easily available in Sun-JDK as $java.library.path)
b) be copied to JVM specific exe directory. $java.home/bin in the
JDK/JRE for Sun-JDK, $com.ms.sysdir in c:\windows\system32
c) Some other directory, leaving it up the user to change the $PATH /
$LD_LIBRARY_PATH(?) environment variables.
Again, I think the user must be queried before .dll files can be
These are normal installation issues. I am a bit unsure on how much I
can reasonably expect distutils to deal with this. From my very
limited experience with distutils, I think distutils is exactly the
right place to put some of the logic that deals with JVM and OS
dependencies as described above.
Buglets and suggestions:
a) Documentation buglet. In the USAGE file for "dist", -f is described
as an alias for --formats. -f does not work.
b) How about allowing for some alias names for the README file. Some
of us lazy double-clicking windows types prefer names like README.txt.
c) Why are "packages" and "py_module" mutually exclusive. One of my
products happens to have a toplevel module which contains "from
pck.Main import *". I think that I find the current behavior limiting.