install_scripts and install_data commands
Hi, I wrote a patch for the above commands. Both commands derive from install_misc, which copies some files to a given directory and is defined in cmd.py. With the attached patch you can now have "scripts=[...]" and "data=[...]" attributes in setup.py. By the way: I was not able to TeX the documentation because I found no howto.cls file (the files are using \documentclass{howto}). There should be a make file to compile all the various .tex files. Bastian -- Bastian Kleineidam -- Just do it. Use Linux. .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^
On 27 April 2000, Bastian Kleineidam said:
I wrote a patch for the above commands. Both commands derive from install_misc, which copies some files to a given directory and is defined in cmd.py. With the attached patch you can now have "scripts=[...]" and "data=[...]" attributes in setup.py.
Cool, thanks! Been meaning to get around to those...
By the way: I was not able to TeX the documentation because I found no howto.cls file (the files are using \documentclass{howto}). There should be a make file to compile all the various .tex files.
Rather than answering you directly, here's the doc/README.txt I just wrote to answer everyone who looks in that directory... ------------------------------------------------------------------------ The Distutils documentation is supplied as two manuals: Installing Python Modules (aimed at system administrators, end-users, and Python programmers who need to add new goodies to their Python installation) Distributing Python Modules (aimed at module developers who want to share their goodies with the rest of the world in the standard way) These manuals will be a standard part of the Python 1.6 documentation set, and are tightly integrated with the standard Python documentation tools. That means that you won't be able to process the LaTeX files here without 1) downloading the latest Python documentation tools, and 2) setting up a fearsome forest of symbolic links to make it all work. Since these two manuals are now included with the Python documentation (CVS version as of 28 April 2000), there's really not much point in trying to process the manuals provided here. You're better off checking out the latest Python documentation -- which is included in the Python source, when you access it via CVS -- and starting from there. For information on getting access to the Python source and documentation via CVS, see http://www.python.org/download/cvs.html If all you really want to do is *read* the documentation, you don't need to process it yourself: see http://www.python.org/sigs/distutils-sig/doc/ for access to the (roughly) current Distutils documentation, in PDF, PostScript, and HTML. ------------------------------------------------------------------------ Hope that clarifies matters... Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ Any priest or shaman must be presumed guilty until proven innocent.
On 27 April 2000, Bastian Kleineidam said:
I wrote a patch for the above commands. Both commands derive from install_misc, which copies some files to a given directory and is defined in cmd.py. With the attached patch you can now have "scripts=[...]" and "data=[...]" attributes in setup.py.
Finally got around to looking over this patch and checking it in: thanks again! However, I just realized a problem: we probably should have a "build_scripts" command, to ensure that the proper "#!" line is in the installed scripts. If someone distributes scripts with "#!/usr/local/bin/python" or however Python happens to be installed on their system, there's no guarantee it'll work on the installation system. But I don't think we should rely on everyone using the "#!/usr/bin/env" hack, either: the first python on the path isn't necessarily the right one. I think the python used to run the setup script is what should go on the #! line. Opinions? Bastien, can you whip up a "build_scripts" command? Should be pretty easy -- just copy the scripts to "build/scripts" and tweak the first line as appropriate. Thanks -- Greg -- Greg Ward - nerd gward@python.net http://starship.python.net/~gward/ Everybody is going somewhere!! It's probably a garage sale or a disaster Movie!!
Hello,
However, I just realized a problem: we probably should have a "build_scripts" command, to ensure that the proper "#!" line is in the installed scripts. Do we have always Python scripts? What about shell scripts, and specifically Windows Batch scripts? See below for my current "Windows" hack in setup.py.
But I don't think we should rely on everyone using the "#!/usr/bin/env" hack, either: the first python on the path isn't necessarily the right one. The "first python on the path" is the correct thing for the user, otherwise the path is wrong. So "/usr/bin/env pyton" yields the correct interpreter to execute.
Bastian PS. Here is my Distribution class form setup.py for LinkChecker: # Autodetect the existence of an SSL library (this is pretty shitty) # Autodetect Windows platforms to include the linkchecker.bat script class LCDistribution(Distribution): default_include_dirs = ['/usr/include/openssl', '/usr/local/include/openssl'] def run_commands (self): self.check_ssl() self.check_windows() for cmd in self.commands: self.run_command (cmd) def check_ssl(self): incldir = self.has_ssl() if incldir: self.announce("SSL header file ssl.h found, " "enabling SSL compilation.") self.ext_modules = [('ssl', {'sources': ['ssl.c'], 'include_dirs': [incldir], 'library_dirs': ['/usr/lib'], 'libs': ['ssl']})] else: self.announce("SSL header file ssl.h missing, " "disabling SSL compilation.\n" "Use the -I option for the build_ext command.") def check_windows(self): if sys.platform=='win32': inst = self.find_command_obj("install") inst.ensure_ready() t = Template("linkchecker.bat.tmpl") f = open("linkchecker.bat","w") # replace "path_to_linkchecker" with install path f.write(t.fill_in({"path_to_linkchecker": inst.install_scripts})) f.close() self.scripts.append('linkchecker.bat') def has_ssl(self): incls = self.find_command_obj("build_ext").include_dirs incls = (incls and string.split(incls, os.pathsep)) or [] for d in incls + self.default_include_dirs: if os.path.exists(os.path.join(d, "ssl.h")): return d return 0
I'm only following this with half a mind at best (sorry), but Bastian had an email that contained:
But I don't think we should rely on everyone using the "#!/usr/bin/env" hack, either: the first python on the path isn't necessarily the right one. The "first python on the path" is the correct thing for the user, otherwise the path is wrong. So "/usr/bin/env pyton" yields the correct interpreter to execute.
Do please remember the problem on Dec Unixes (which appears to be) that if the environment is large (i.e., many environment variables) then /usr/bin/env falls back to *printing* the environment variables, instead of executing the given program (gods know why, but this is Dec). So, for instance, on the Dec Alpha Unix boxes at work here, the #!/usr/bin/env" hack is a consistent failure! (not that I have any *better* suggestion - just don't assume it's a full solution). Tibs -- Tony J Ibbs (Tibs) http://www.tibsnjoan.demon.co.uk/ Give a pedant an inch and they'll take 25.4mm (once they've established you're talking a post-1959 inch, of course) My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)
On 12 May 2000, Bastian Kleineidam said:
Do we have always Python scripts? What about shell scripts, and specifically Windows Batch scripts? See below for my current "Windows" hack in setup.py.
Good point -- it would be nice to use 'scripts' for shell scripts, MS-DOG batch files, and Python scripts. But I bet you can do a fair job of distinguishing those three by looking at a mix of extensions and #! line; and if you can't figure something out, assume it's a Python script.
The "first python on the path" is the correct thing for the user, otherwise the path is wrong. So "/usr/bin/env pyton" yields the correct interpreter to execute.
Not at all! Two possible scenarios come to mind: * I live life on the edge, so Python 1.6a2 is my "default" Python, but I'm installing something for a bunch of other users -- so it should use Python 1.5.2. Then I would run (eg.) python-1.5.2 setup.py install ...and I would damn well expect that any scripts installed by that distribution would (by default) be run by the Python 1.5.2 interpreter that I used to build/install the application. * I don't live life on the edge, so Python 1.5.2 is my default Python. But I've just downloaded some cutting-edge toy that requires 1.6 Then I would run (eg.) python-1.6a2 setup.py install ...and again, I would certainly expect any scripts installed by this distribution to be run by my Python 1.6 interpreter. And the arguments against always relying on #!/usr/bin/env are compelling -- I have long suspected it's a bit dodgy to rely on that across Unices, and the other posts in this thread confirm my paranoia. (With Unix, things are never as bad as they seem -- they're worse.) (Oh yeah, that's true for all operating systems...) Greg -- Greg Ward - Linux nerd gward@python.net http://starship.python.net/~gward/ I want you to MEMORIZE the collected poems of EDNA ST VINCENT MILLAY ... BACKWARDS!!
I will work on the build_scripts command. Strange is that the CVS repository does not have the install_scripts.py command. The code snapshot has this file. I am using cvs update -PAd. CVS Root is :pserver:distutilscvs@cvs.python.org:/projects/cvsroot Good point -- it would be nice to use 'scripts' for shell scripts,
MS-DOG batch files, and Python scripts. But I bet you can do a fair job of distinguishing those three by looking at a mix of extensions and #! line; and if you can't figure something out, assume it's a Python script. I assume we will install the DOS batch files only on Windows systems.
So after all the build_scripts command will also affect the install_scripts command. Bastian -- Bastian Kleineidam -- Time to close your windows: Storm Linux .~. http://fsinfo.cs.uni-sb.de/~calvin/official/ /V\ // \\ /( )\ ^`~'^
participants (3)
-
Bastian Kleineidam -
Greg Ward -
Tony J Ibbs (Tibs)