Hacker News Reader

Comment by madelyn | Hacker News Reader

I have never understood the need for all the different tools surrounding Python packaging, development environments, or things like Pipenv. For years, I have used Virtualenv and a script to create a virtual environment in my project folder. It's as simple as a node_modules folder, the confusion around it is puzzling to me.

Nowadays, using setuptools to create packages is really easy too, there's a great tutorial on the main Python site. It's not as easy as node.js, sure, but there's tools like Cookiecutter to remove the boilerplate from new packages.

requirements.txt files aren't very elegant, but they work well enough.

And with docker, all this is is even easier. The python + docker story is really nice.

Honestly I just love these basic tools and how they let me do my job without worrying about are they the latest and greatest. My python setup has been stable for years and I am so productive with it.

View on HN

I'm firmly set on virtualenv with virtualenvwrapper for some convenience functions. Need a new space for a project? mkvirtualenv -p /path/to/python projectname (-p only if I'm not using the default configured in the virtualenv config file, which is rare)

From there it's just "workon projectname" and just "deactivate" when I'm done (or "workon otherprojectname")

It has been stable and working for ages now. I just don't see any strong incentive to change.

I have been doing this starting Ubuntu 14.04. it's been stable even when I upgraded now to 18.04 which has python 3 as default. The only downside compared with tool such as pipenv is the automatic update of packages that pipenv can offer and it's ability to be integrated into CI/CD pipelines.

Yup, that's my exact setup. Haven't found a need to do more than that for years.

I am fine with venv, but I need to keep a list of root dependencies and separate dev dependencies from those that the product needs to work. Since I need tools for this functionality, why not just use pipenv or poetry?

For years, I have used Virtualenv

Isn't this just a variant of what the original comment is critiquing, though? In order to sanely use Python and external dependencies you need some highly stateful, magical tool that does 'environments' for you. The conceptual load of this is quite high. Adding docker only makes it higher - now you're not merely 'virtualizing' a single language runtime but an entire OS as well - just to deal with the fact your language runtime has trouble handling dependencies.

if the conceptual load of having a large collection of binaries separately from your project (and ready for reuse!) is that high, you probably should use something else. I wonder how C/C++ people just manage this hardship...

(and for all npm-friends: it's exactly the same "conceptual load" which arises from having node 8 and 12 around. except that these will be just incompatible by default, so noone bothers)

I don't understand the point you're making, where does a 'large collection of binaries' come in? The thing I'm talking about is right in the name 'virtual environment'. Or are you simply answering the GP's comment about this being a potential wart in Python with the suggestion that people should just use something else?

the point is that the classic virtualenv does not take care of different base distributions (3.5,3.6,3.7...). You have to install them yourselves and switch them in your PATH before setting up a virtualenv. if this is too much "conceptual load", I wish the parent good luck with finding something not having this problem ;). If there are binaries involved, there is the additional problem that you also depend on compiler features and C-libs, which I wish everyone good luck in replicating in their CI for any language (containerization and NixOS/guix/spack are approaches to that problem)

I think we are talking about completely different things. Forget the actual virtualenv and Python for a sec.

Imagine you want to check out the hypothetical language Jagoust. This goes something like so - you install Jagoust and maybe some Jagoust tools. You fire up your interactive environment and set it up so it knows where Jagoust and its tools are. Using your enviornment you do things like tell Jagoust where your project is or which particular version of Jagoust to use, etc.. And that's pretty much it and while the details are different, the process is quite familiar to you since it just leverages your standard interactive environment in ways mechanically similar to Rugoja, another language you know.

Later you decide you want to try the language Snek. The first thing you notice in the Snek tutorial is that your standard interactive environment is somehow not good enough - you need a meta-environment for it and your project. Perplexed, you google some more docs and ask some Snek people and find out that meta-environment used to be how things were done but these days, you probably want a quasi- or para-environment. But why do you need an environment for your environment? You do not know. Such are the mysteries of the Snek.

Well, you need some way to switch between different variants of Jagoust in the first setup too? And if everything is so well integrated (w/o bash-scripts and all...), just name Jagoust ;).

Noone forces people to use virtualenvs with "snek"/Python. They can always install python somewhere and "pip install" packages into the installation hierarchy, switching around different hierarchies with bash-scripts (and now have a look what all the other interactive environments do...).

Last time I looked, it was very tedious to set up `pip` to be secure and pin your dependencies to hashes. Without this, a compromise of a library's pypa account would allow them to execute arbitrary code on your system, assuming you didn't notice the change.

You can use `pip-tools` to get something like a Gemfile/package.json, but there are a few restrictions that are suboptimal.

So Pipenv/Poetry are the current best ways to get something like the package management story that other languages like Ruby and JS have had for a long time (and that Go's been polishing recently too).

Conda does as well, and a hell of a lot more, not sure why it is so rarely mentioned.

What do you find restrictive about pip-tools? It's been working excellent for me.

I was going to say that pinning hashes seems to be painful, but since I last looked it now has a --generate-hashes flag.

Also if you want to link directly to a git repo, you can only install it in editable mode, you can't just install it with the rest of your packages (means you get a `src` directory where you ran pip, which makes Dockerizing slightly annoying, and probably impacts performance slightly).

Maybe this has also been fixed since I last upgraded.

Since `pip-tools>=3.7.0` it supports links to git repo URLs without editable mode and --generate-hashes works as well (since 3.8.0 version).

You’re absolutely right. I use pipenv almost entirely because it can activate a local environment automatically when entering a folder in terminal. That and the fact that my virtual folder lives in ~/.local let’s me work directly in Dropbox. Nothing I couldn’t live without.

`poetry env` works just fine without pyenv.

Reply on news.ycombinator.com