131–140 of 251 posts
FYI - Fedora 13 shipped with Python 2.6, Fedora 14 is going to ship with Python 2.7 and 3.1 in parallel. Not every distribution ships ancient versions. I also recommend using virtualenv and pip, these tools make it much easier to create an easily reproducable Python environment.
True, but I have had no end of problems using Python apps on Fedora. I now pretty much kill the packages straight away and reinstall from source.
Earlier quoted context omitted.
This is very interesting and is what RVM in the Ruby world was designed to solve in some way. So maybe we need a widespread and useful PVM. This feeds into an observation of mine I made over five years ago but that seems to be ever more relevant as time goes by. Linux and BSD seem to have "solved" the packaging problem through mega-repositories with dependencies and access to source code. However your favorite langua…
have there own repositories that are _not_ linked into the systems way of doing things One approach is to have a system that packages everything in the language-specific repository for the distro. Haskell on Archlinux is an example of this. I'm not a fan of actually using the language-specific packages because I like the rolling release model and end up having to do some manual work to reinstall all my packages when…
Earlier quoted context omitted.
True, but I have had no end of problems using Python apps on Fedora. I now pretty much kill the packages straight away and reinstall from source.
Have you filed bug reports with those packages?
The main problem is that I could upgrade a couple of systems to fix the bug but doing that tends to break python (with the infamous _md5 error) spectacularly :)
Catch 22.
Earlier quoted context omitted.
Stuff that belongs to the OS (but runnable by all users) is in /usr/bin. That's FHS. Stuff that's yours is wherever dir you specified when you ran: export WORKON_HOME=$HOME/.virtualenvs Seriously. Use virtualenv (and virtualenvwrapper). http://www.doughellmann.com/projects/virtualenvwrapper/
What about stuff that belongs to me (the sysadmin) but runnable by all users? /usr/local/bin? /opt/bin? /my/homemade/solution/bin? There is a bunch of stuff that doesn't (shouldn't) belong to the OS, but still be runnable by all users without all of them needing a copy in their $HOME directory.
You can blow away your /usr/local and start from a new ports tree and build it all back up without adversely affecting the system.
Everything system related is in /bin, /sbin, /usr/bin, /usr/sbin depending on whether it needs to be accessible when the system has just / mounted or when /usr is mounted as well.
So in single user mode with just / mounted you have access to various different utilities. Mount /usr and you can expand upon that.
Back in the old days when FreeBSD required perl in its base system switching to a newer version didn't break any of the base system tools (or maybe I just never noticed).
There is something nice about a layout that is properly documented and makes sense: http://www.freebsd.org/cgi/man.cgi?query=hier&apropos=0&...
Instead of inventing your own syntax, why didn't you use a portable syntax like XML, JSON, YAML, or better yet, libconfig[1]? Please compare the libconfig test file to the mongrel configuration file: http://www.hyperrealm.com/libconfig/test.cfg.txt http://mongrel2.org/doc/tip/docs/manual/book.wiki#x1-190003.... The mongrel conf is a subset of libconfig; it doesn't use the more advanced features. Plus libconfig has bi…
The mongrel2 configuration architecture makes it pretty easy to write a libconfig configuration shell. All it would need to do is translate the libconfig stuff to sqlite. If using libconfig is a good idea, it'll win. P.s. imho, this is the cool thing about the Mongrel2 stuff. The good ideas can always win, because there really just isn't a whole lot to Mongrel2-core, and everything else is decoupled.
Python brought this on itself by having no respect for compatibility between versions. There's really no such thing as the Python language, only "Python 2.2", "Python 2.4", "Python 3". If you want to run Python scripts, you need to have three or four different Python runtimes installed, and that's asking a lot of both the distros and of users who need to keep everything straight, and probably even hack the #! at the…
Bullshit. We (python-core) are obsessed with backwards compatibility. Adding new features that aren't in old version is the source of this problem. Python 3 is by far, the biggest intentional deviation from the "don't break existing scripts" mantra that's been in place for years.
Why was NLTK stuck on Python 2.4 for years? I might use Python to use NLTK, but why do I have to choose an old Python to get it to work... And what if I want to use it w/ software that needs Python 2.6?
Python needs something like the "Go PHP 5" campaign (which pressured projects/hosting companies to drop support of PHP 4: http://gophp5.org/ ).
Earlier quoted context omitted.
I think we agree. If I were doing an OS now, I'd also ignore the FHS completely, but more to the point: I wouldn't use anything that remotely resembles it either. / would have one dir: /myos And all OS components are under there: /myos/bin/python People can install anything they want outside /myos, but I'd make it very clear that the OS owns this folder and it should not be modified.
Yup, that's basically what I'm looking for.
It's a lot of work - I think I ended up trying to write an iproute2 replacement using ctypes and quit. I wonder if anyone else would be interested...
Earlier quoted context omitted.
Not every distribution ships ancient versions. RHEL, meanwhile, does not ship 3.1, 2.7 or 2.6. And to be perfectly honest, if you're seriously distributing Python software you have to take RHEL into account -- "Fedora ships something newer" doesn't help.
The EPEL5 repository has Python 2.6 available - http://download.fedora.redhat.com/pub/epel/5/SRPMS/repoview/...