Hacker News Reader

Comment by tyrion | Hacker News Reader

Those are needed to compile different versions of Python with pyenv.

Usually distributions bundle one or two specific versions of Python. Pyenv makes it super easy to install and use all the versions of Python that you want.

Even though for most people it might be enough to just use whatever version of Python comes installed with your system, for a team it might be important that everyone has the exact same version.

Moreover, pyenv-virtualenv makes it painless to use virtualenvs and so I recommend you give pyenv a try even if you do not need additional Python versions.

View on HN

Again, do these tools really require a C compiler toolchain? If so, they are completely out of the question - they add much more complexity then they could possibly fix.

Why not just install the required version of Python, maybe from a 3rd party repo if not available in the main repos? Why would I ever want to get a compiler toolchain to get my Python interpreter?

> Why not just install the required version of Python, maybe from a 3rd party repo

That's the thing. pyenv just downloads the source code of the specified Python version, and then compiles it on your machine. They did that to be agnostic of the OS you're running on.

But they are not agnostic of the OS. In fact, they have a huge dependency on the C toolchain, which I have to fix apparently.

Could you explain why it is such a deal-breaker in your opinion?

It is a single `apt-get install` (which probably downloads less MBs than our typical `npm/yarn` install).

Consider that if pyenv came pre-packaged for ubuntu/debian, those packages would be runtime dependencies and then you would just need to `apt-get install pyenv`.

What if I already have a different C toolchain installed? Would I now need "cenv" to keep the pyenv C toolchain and my other C toolchain separate?

If you don't need to use multiple version of python like me, then you don't need it. Just use the built-in venv module in python 3 to create and manage virtuanenv. for example, simply run `python -m venv .venv` to create a new virtualenv in your project dir, and vscode will automatically recognize it when you add the project dir into your workspace.

But having c compiler toolchain available is pretty much standard practice when using python (or nodejs, ruby, etc) because you might need to install some library that requires compilation from source (e.g. psycopg2). If you don't want that, you'll stuck with installing those 3rd party libs from your distro's repo, which might be out of date or outright missing (especially for less popular packages).

Pyenv often is the easiest 3rd party source for additional pythons.

Real scenario I'm in right now:

- Need to build libraries to support 2.7, 3.6, plus future proofing for >=3.7

- CI workers have images which only python 2.7 and 3.6, platform team too busy to update them

- Mac Homebrew only supports >=3.7

There's no common environment between anything unless we use pyenv

Can't you simply download Python 2.7, 3.6 and 3.7+ to separate folders, and use those in your different projects?

I understand that virtualenv and maybe even pyenv are useful if you need different requirements for different projects using the same version of Python, as apparently pip installs packages globally. But for your setup, I don't get why something like pyenv really helps...

I gave up trying to install python 3.6 natively on my mac after a few hours. If there is a way it can be "simply" be done, I did not find it.

> Can't you simply download Python 2.7, 3.6 and 3.7+ to separate folders, and use those in your different projects?

Yep, most people can just do this. Then, they want a little script over the top that downloads the different versions of Python for them -- just to make life easier for them. Wouldn't it be handy to also script the installation? It'd also probably be useful to automatically setup the version of Python I want to use when I switch folders, so I'm not constantly running the wrong version when I change projects.

... et voila, we've reinvented pyenv :).

My workplace got burned recently using this tool for some deployment reasons . I have to be honest , my experience with it in other ways wasn’t ideal. I won’t be using it again.

Reply on news.ycombinator.com