Hi all,

I'm afraid this is a kind of vague enquiry but I'm loosing the will to live. I didn't realise getting into Python would raise so many irritating problems.

All I want is a Python environment with the necessary packages (sciency, in my case, for dealing with geospatial data and statistical analysis. I don't have a list as such but I know there are a lot).

Questions:
1) Should I care about different Python versions? My system is brand new, so why not use the *newest* version of Python? Should I just stick with version 2.7? (Why does such a widely used language seem to be schizophrenic anyway?!)

2) What is the most efficient way to get the packages I need? Do I actually have to download and build from source every time I hit a new dependency? For real? Like if I want numpy, I have to download a tarball and execute a build / install command? (I did this before and again nearly hung myself after about the tenth install). I usually use the language 'R' for analysis, in which I simply tell it to install new libraries from within the R environment, and it downloads source from there and compiles against system libraries, no hassle. Can Python not do this?

3) Should I use packages like Anaconda? I don't plan on becoming a professional Python developer.... I installed but it (i) failed to provide packages, or at least Python didn't seem to recognise them after a moderate amount of messing around, and (ii) I was able to install packages via conda (e.g. conda install netcdf4), but that downloads and installs system libraries that I already have! (e.g. curl, zlib etc, wtf?) I want to build against one common version of, say zlib, not live in some bizarre multi environment world...

All I want to do is use Python to do some actual work. How should I go about this cleanly, and with the least amount of hassle?

Any guiadance appreciated. Many thanks.

Hi,

My advice is first to run Slackware64-14.1, not Slackware64-current.

There is no benefit to run Slackware-current (only provided for testing purposes) for someone not acquainted to Slackware, just more hassle ahead.

Then, just use the version shipped in the Slackware-14.1, i.e. 2.7.5. I doubt that you really need a newer one.

You can easily build then install additional Python packages on Slackware see here.

Don't forget to read http://slackbuilds.org/howto/ and http://slackbuilds.org/faq/ first.

And to answer all your questions about Slackware, visit http://docs.slackware.com

Thanks.

This is really more of a Python issue than a Slackware issue (but in Ubuntu world, all you need is "sudo apt-get install <python_pkg>" or whatever which makes it slightly less painless... not that I want anything to do with Ubuntu)

However, it seems that, not to mention the potential complications of running some kind of environment manager like Anaconda, every package in Python that I need is going to need a separate download, compile and install (plus dependencies). Since many of these packages are not provided by Slackware, Slackbuilds, Alienbob etc. I foresee a long and painful process. (And even if they were provided they are not conveniently provided in a single repository that can be accessed in "sudo apt-get" kind of way).

From within Anaconda, it does seem straightforward to get Python packages installed but it is not clear to me how these relate to system wide packages. I don't want inconsistencies between Python code built against newer libraries than are in my system, for example. Why do I need another layer? Can't I simply run some kind of command within Python to get and build required libraries (like 'R')? (I cannot find such a command so I assume not, or perhaps I just need to spend even more time learning about Anaconda??). Otherwise, if I need, say, 20 packages with dependencies (which seems to be the way with Python) then I'm likely to need to have to visit 20 different sites, download, compile and install 20 tarballs, plus any dependencies. As a Slackware user there doesn't seem to be a simple and obvious approach (but then maybe that's why something like Anaconda is very useful).

You can also use pip and virtualenv. This lets you keep your own python install and if you don't like it you can remove it and create another or switch between python enviroments.

I have done this and I like this because I don't have to add ann complexity to the OS install. I keep all my pythons in separate dirs. I also have a python 3 setup. I did build my own python 3 from python.org tar ball.

Ok, thanks, that sounds like a way to go, I'll give it a shot. (I did build Python 3 successfully but I got confused about how Python packages would get handled.)

With slackpkg+ you can work with many binary repository simultaneously. The Slackbuilds is not binary, but you can use slackrepo to have you own binary repository, consisting of packages built from Slackbuilds in completely automated way (or use slackonly.com).

Its safe to have both python3 and python2 installed at once in slackware.

Just use the Python interpreter (2.7) that comes with Slackware. It works fine, it's there, and it has the very compelling feature of being included with Slackware.

I would just install pip from SlackBuilds.org and then install everything after that with "pip install <package> --user" (as a user, not as root). That will put the packages in ~/.local, and it should serve your needs fine. Installing packages with pip automatically downloads and installs dependencies. VirtualEnvwrapper is great, but it sounds like overkill for what you described as your own needs.

(First reaction: "wtf? no.")

You should definitely not use Anaconda on Slackware. If you already did so as root then you should probably reinstall Slackware.

Running pip as a user is safe though.

How do you manage packages with pip? Upgrading and removing? I find it best to install everything via a slackbuild so that I can cleanly remove packages.

To upgrade a package, you just "pip install" the package again. To remove a package, you "pip uninstall it" or just delete its directory. (obviously safe if they're in ~/.local).

Well, yes.

I meant how do you keep track of which packages to upgrade, which are installed and which you no longer need?

The "which ones you no longer need" question is the one that changes things. It implies to me a need to keep track of which Python packages you're using which project. That's what VirtualEnvWrapper is for.

To keep track of which packages you used pip to install into ~/.local, you simply "pip list --user". The list isn't large if you're installing your Python packages from SBo, Alien Bob, etc when you can (they don't interfere with each other). By "which packages to upgrade", I assume you mean "which packages have newer versions available". I don't worry about that.

will show you the installed packages.
will search for a package in the database. If you have the package already installed it will show you which version you have installed and which version is the latest.

Well, for which package you no longer need, how should anyone but yourself know which packages you use in your programs?

For more info

Thanks for the discussion, its very useful.

Maybe I misunderstood Anaconda, and I probably need to better understand the modern world of package managers, but can I not use it to create some kind of "clean" development environment and install packages I want - and then simply delete the whole environment if I wish, without affecting the system? (I'm not saying this is what I want, but isn't this the point of it?)

I think python3 includes virtualenv. I really like the virtualenv as I can remove the entire env and create a new one easily.
Also I don't have to install any packages as root.

Here is a recent example of why I use virtualenv. A software package uses scons for the build and I didn't want to install it system-wide because I really didn't know what it would entail. I created a virtualenv and installed scons there. It all works fine and I leave that virtualenv there for whenever I need scons.

Also I wanted to look at some python web frameworks and a virtualenv let me evaluate each one and then delete the entire virtualenv, knowing that everything for the framework is removed.