Other Help Topics :: Python on DSL



I still cant see it in UCI. Any time on when it will be?
After it's been through testing. It's still in testing:
http://distro.ibiblio.org/pub....testing
Quote
I just compiled a python-2.5 uci. Basically, two directories: Keep the read-only stuff in /opt/python-2.5, and let the directory for user-installed stuff be /opt/python-2.5_site-packages. How does python find it? Just replace /opt/python-2.5/lib/site-packages with a symlink to /opt/python-2.5_site-packages.

So, I've done the above, plus some extras such as symlinks in /usr/lib for libpython2.5.so* so you can compile stuff that needs to find the python shared lib. As well as the obligatory symlinks in /opt/bin for the python binaries plus a /usr/bin/python symlink, of course.

I've been struggling for a while to make hplip work using Roberts python.uci extension - it compiles without problems to /opt/hplip but then none of the hp-* python functions work. I just remembered your post and realised this is possibly an issue of the /site-packages folder or libraries or both - I'll try and modify the python.uci extension with a symlink to test the site-packages theory. (I suppose that if everything were compiled in /usr/local this problem would not exist.)

I like the idea of compiling to /opt/whatever but it's a real pain in terms of libraries, headers, etc - is there a smarter way to deal with this than symlinks to /usr/bin-lib-include and/or adding /opt/whatever/bin to the path (which is anyway limited to the terminal window in question)?
Have you tried to see if the Python 2.5 package will work?
As far as I know, older Python mydsl packages are only runtime files, which probably means compiling programs with them isn't going to be successful even if you make the directories writable.

Quote
is there a smarter way to deal with this than symlinks to /usr/bin-lib-include and/or adding /opt/whatever/bin to the path (which is anyway limited to the terminal window in question)?
The smarter way, in my opinion, would be to try to understand why you need to do these things and when to choose one way over the others.

Personally I'm not at all into using symlinks in /usr/bin-lib-include. These directories are initially read-only in DSL. I like to try keeping them that way, and also prefer the convenience and safety of not needing to mess with the base system (of _any_ distro) unless absolutely necessary. Most changes of this kind can be made to files in your home directory, keeping system files untouched.

Modifying variables may be limited to the current terminal, but only if you make those changes from a terminal window. Your startup scripts (.bash_profile, .bashrc, .xinitrc) are there to allow you to make these changes before you open an interactive shell.
You can export the PATH variable from /home/dsl/.bash_profile to include /opt/whatever/bin, and never need to do it manually. Even if that directory doesn't exist (if you don't have the related extension installed at the moment) it's still in PATH for future use. The same can be done with the LD_LIBRARY_PATH for finding libraries.

Another option is to create your symlinks in /opt/bin instead of /bin, /usr/bin, or /usr/local/bin. This directory is already writable and in PATH. The limitation with this is /opt/bin is at the _end_ of path, which means you cannot override a system executable with your own by adding it to this directory. But there are ways to deal with that, too, such as creating /home/dsl/bin and adding that to the _beginning_ of PATH.

Also, use aliases. Aliases are extremely handy, not only for allowing you to run commands easily that are not in PATH, but for running complex or cryptic commands with a few keystrokes (alias nocomment='egrep -v "#|^ *$"'). The limitation here is that aliases are limited to your shell, and are ignored by most other applications.

As far as headers go, I think that is dependent on what you're compiling and how it is compiled, but the only time you need to bother about them is while you're compiling, so it's not such a big deal. When using headers installed in /opt/myapp/include for a C program, typically do "export CFLAGS=-I/opt/myapp/include" before compiling, and "export LDFLAGS=-L/opt/myapp/lib" if there are libraries that are not available in DSL base. In a typical source package with a configure script, "configure --help" will generally tell you what variables apply. I guess you could probably export these variables from a startup script the same way as PATH, though it never occured to me to try it until this moment. But as I said, it's only important while you are compiling.
Veering off on a tangent...

I don't understand a blanket objection to using a file hierarchy like /usr/local that's specifically intended for applications and libraries added locally, particularly if those things are to be shared among all users on a Unix host. I also don't understand not using symlinks to do what they're intended to do (see below).

Per the FHS standard,
Quote
The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally installed software must be placed within /usr/local rather than /usr unless it is  being installed to replace or upgrade software in /usr.

http://www.pathname.com/fhs/pub/fhs-2.3.pdf

I realize Linux doesn't adhere to stricter Unix standards, so /usr/local is used variously throughout Linux distros. Red Hat's use of /usr/local:
Quote
Since system upgrades from Red Hat are done safely with the rpm command and graphical Package Management Tool application, you do not need to protect files by putting them in /usr/local. Instead, we recommend you use /usr/local for software that is local to your machine.

http://www.redhat.com/docs....hs.html

In contrast, Debian doesn't install anything to /usr/local to comply more strictly with FHS. Per Debian's documentation, "Debian packages must not use that directory[/usr/local], since it is reserved for system administrator's (or user's) private use."
http://www.debian.org/doc/maint-guide/ch-modify.en.html

I kind of understand the rationale used to justify your position in the sense that the CD/frugal are read-only, but you parenthetically added "_any_ distro" and I don't understand why /usr/local would be avoided in a standard installation. Otherwise, developers need only fill /usr/bin with apps and not even make a /usr/local directory hierarchy except to be compliant with FHS (like Debian does). Many distros even advise setting /usr/local in a separate partition because it's intended to be a unique-to-the-system directory hierarchy; Slackware comes to mind in this regard -- if there are more than two standard / and swap partitions available during setup, the installation script prompts to see if the user wants to put /usr/local on its own partition. Never mind that /usr/local is the default prefix for most source you'll ever compile.

I know DSL is a little different because of extensions like UCI and UNC and because /opt is used in frugal for persistent partition, but that doesn't obviate the reasons for why /usr/local exists. It shouldn't be avoided as though it were sacred ground.

I don't use aliases to take the place of symlinks, and I don't use symlinks to take the place of aliases. I don't think they should be considered equivalents even though I accept you can find more than one way to skin a cat. An alias would require a full path, a symlink allows a standard call without calling with an atypical path (which would make an alias using whatever is linked even easier since it doesn't require the atypical path to be included). Symlinks reroute to sensible, typical paths. Aliases are intended to reduce complex commands into simpler keystrokes, such as the example you gave.

Finally, I don't understand your concern about convenience or safety other than your ideas keep things a little more compartmentalized with respect to what's on the CD versus what you add -- which doesn't sound too appealing to me because my systems are mine, not a developer's. It's still no more secure adding a link to any other directory in PATH like /opt/bin than it is in /usr/local/bin -- same net effect.
Next Page...
original here.