11–20 of 78 posts
pip is a neat system and all, but I still don't see why to use that versus a system package?
pip is a neat system and all, but I still don't see why to use that versus a system package?
Also, I wouldn't like to install some packages system-wide (a friend's personal project from a github repository) so I use pip and virtualenv in a similar manner as the article recommends to maintain a per project dependency library.
That's how I see it :)
> Choose Python 3 only if you need to and/or fully understand the implications. I would apply the "if you need to" part to Python 2. "3 if you can, 2 if you must"
Novice: "I want to do X" Internet advice: "Use package Y" Novice: "Okay , wtf nothing is working" Novice: "Oh, wow, this doesn't support Python3 yet. Now I have to ignore all the internet advice and forge my own path, OR port all my code back to 2.7! This language sucks!"
The alternative seems preferable: Stuff works, but occasionally you don't get a whiz-bang feature (you "only" get 2.7's feature set, poor you). Five years pass, you learn the language. Now you've gotta learn a bunch of new habits, which sucks, but it's not as bad because now you're pretty good at Python, so the easy parts are easy.
I'm pretty sure a "Ruby Ecosystem, An Introduction" guide is exactly what I need.
I'd love to have one of these for Ruby. Every time I want to try out something written in Ruby I run head-first in to the packaging problem - Debian and Ubuntu don't appear to like shipping a working gem (presumably because it conflicts with how apt likes to do things) and the documentation on how to resolve the resulting inscrutable error messages isn't particularly easy to find. The Mac is a bit better, but I still…
If you're on Ubuntu LTS you should install PIP from PyPI (easy_install pip), since the system package management version is outdated and it doesn't have the (very useful, since PyPI likes to go down) --use-mirrors install option. That would be my only recommendation.
I'd love to have one of these for Ruby. Every time I want to try out something written in Ruby I run head-first in to the packaging problem - Debian and Ubuntu don't appear to like shipping a working gem (presumably because it conflicts with how apt likes to do things) and the documentation on how to resolve the resulting inscrutable error messages isn't particularly easy to find. The Mac is a bit better, but I still…
- Use http://beginrescueend.com/ to install ruby itself
- Use http://gembundler.com/ to manage project-level dependencies
Both of those sites have good examples, but if no one steps up I might just write something like the linked guide when time frees up.
* the site module, which is imported by default and is what is responsible for setting up the default sys.path. You can skip 'import site' by running python with the -S switch. the site module is written in python, so you can scan through it and understand how python starts up and inits.
* PYTHONSTARTUP env variable, which points to a python file that is run (like a bashrc, or AUTOEXEC.BAT, if you prefer) on interactive prompt startup. I use this to import custom paths and modules that I want to access from the REPL, such as Google App Engine
* I use pip with local repositories. clone the repos of the libs you need, and then pip install in the virtualenv from that local clone:
$ pip install git+file:///Users/nik/.python-packages/tornado
$ pip install git+git://nikcub@github.com/nikcub/tornado
* don't store the actual project inside the virtualenv. the virtualenv provides the execution context (setup and torn down using the virtualenvwrapper helper scripts). a common practice is to place all your virtualenvs into a directory like ~/.virtualenvs. you should never have to cd into this dir, access it using the wrappers and pip. (edit: also agree with comment below that you shouldn't be sudo'ing).
* just a quick add, I think it is definitely worth learning how to install python from source.