
Hi, 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 java command. 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 for MS-jview. 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 copied. 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. Any thoughs? 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. regards, finn

On 25 December 1999, Finn Bock said:
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.
Finn -- thanks for all the suggestions. I have skimmed them, but not come close to absorbing them. JPython support is definitely a medium-term goal for the Distutils, but it certainly wasn't planned for 0.1. I also wasn't planning on it for 0.2, but I am open to persuasion and/or threats. ;-)
I totally agree. The JVM is just another sort of "platform", and should probably be dealt with on the same level as "posix" or "nt". I hadn't thought previously about the differences between JVMs; I had been naively thinking that we would add "java" support to the existing "posix" and "nt" (and someday, "mac") support. Guess it won't be that simple... sigh...
a) Documentation buglet. In the USAGE file for "dist", -f is described as an alias for --formats. -f does not work.
D'oh! Well, it *used* to be -- "-f" is now an alias for the global command-line option "--force", which was snuck in somewhere around 0.1.1. Fixed.
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.
Oh, all right. It's also nicer for HTTP servers that way. Damn and blast this cross-platform targeting. Why can't everyone just be happy using Unix? ;-)
Mainly laziness -- I had a sneaking suspicion that allowing both of them at the same time might have subtle problems, so I sidestepped the whole issue. Make a good case for where they're both needed, and I'll reconsider. (I agree that it's limiting, but *how* limiting?) Greg -- Greg Ward - software developer gward@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

On 25 December 1999, Finn Bock said:
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.
Finn -- thanks for all the suggestions. I have skimmed them, but not come close to absorbing them. JPython support is definitely a medium-term goal for the Distutils, but it certainly wasn't planned for 0.1. I also wasn't planning on it for 0.2, but I am open to persuasion and/or threats. ;-)
I totally agree. The JVM is just another sort of "platform", and should probably be dealt with on the same level as "posix" or "nt". I hadn't thought previously about the differences between JVMs; I had been naively thinking that we would add "java" support to the existing "posix" and "nt" (and someday, "mac") support. Guess it won't be that simple... sigh...
a) Documentation buglet. In the USAGE file for "dist", -f is described as an alias for --formats. -f does not work.
D'oh! Well, it *used* to be -- "-f" is now an alias for the global command-line option "--force", which was snuck in somewhere around 0.1.1. Fixed.
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.
Oh, all right. It's also nicer for HTTP servers that way. Damn and blast this cross-platform targeting. Why can't everyone just be happy using Unix? ;-)
Mainly laziness -- I had a sneaking suspicion that allowing both of them at the same time might have subtle problems, so I sidestepped the whole issue. Make a good case for where they're both needed, and I'll reconsider. (I agree that it's limiting, but *how* limiting?) Greg -- Greg Ward - software developer gward@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
participants (2)
-
Finn Bock
-
Greg Ward