My Python Development Environment, 2020 Edition • Hacker News Board

Re: My Python Development Environment, 2020 Edition

#181

Post by roel_v » Tue, Nov 12, 2019, 11:54 AM UTC

coldtea wrote: post #168

TheChaplain wrote: post #158

Earlier quoted context omitted.

I never had any issue myself, but I guess that is because I use the standard tools: python3 -m venv /tmp/foo /tmp/foo/bin/pip -U pip wheel /tmp/foo/bin/pip -r requirements.txt I understand some might not like it, but really, it's simple and it works.

Note how you only use one version of Python above, which is not the case discussed.

Until now I just deal with that by always explicitly specifying the whole path to the python executable. Granted my needs are very run-of-the-mill, but wouldn't that suffice for many people? I've tried several times over the last few months to get into all this python environment/package stuff, but it all feels like yak shaving... much like the hours and hours I spend customizing vim years ago, which were fun (at that time) but which weren't 'productive' in that they'll never in my lifetime pay themselves off.

Re: My Python Development Environment, 2020 Edition

#182

Post by Rotareti » Tue, Nov 12, 2019, 12:01 PM UTC

_AzMoo wrote: post #85

Rotareti wrote: post #59

Earlier quoted context omitted.

Since you are familiar with nodejs: poetry == npm pyenv == nvm pipx == npx No big difference, IMO.

Right? It's literally the same set of issues. Package Management - npm? bower? yarn? Which should I use this week? Interpreter Versions - Revisiting a project I last touched 2 years ago on node 8 has a load of locked dependencies that only work on that node version. OK, let's bring in nvm so I can get a dev environment going. Executable Packages - oh no I've got two different projects with different and incompatible…

> Every ecosystem has these problems, and if they don't it's probably because they're still relatively esoteric.

Exactly! I'm not aware of any non-compiled language where (all) these issues are solved much better. I can be very productive with the tools I mentioned above and I'm glad that they work almost identical for both my main drivers (Python and JS/TS).

Re: My Python Development Environment, 2020 Edition

#183

Post by Rotareti » Tue, Nov 12, 2019, 12:19 PM UTC

dec0dedab0de wrote: post #61

marmada wrote: post #31

Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…

I love Python. Throughout my life I tried learning many languages, and Python is the only one that really stuck, and was able to do useful things. Learning Python changed my life, in 5 years my salary more than doubled, and for the last 5 years I've been a full time developer. A coworker likes to say that I think in Python. That said, I 100% agree. I don't have the answer, except that I wish that there was one offici…

> and is there maybe a way to come up with a unified language dependency manger?

For interpreter/compiler version management you can use asdf [0]. It works for all popular programming languages. You can use it to replace tools such as pyenv, nvm, gvm, etc.

[0]: https://asdf-vm.com/#/

Re: My Python Development Environment, 2020 Edition

#184

Post by xchaotic » Tue, Nov 12, 2019, 12:23 PM UTC

I love Python syntax, but I still haven't found a sufficiently popular way that can deploy my code in the same set of setting s as my dev box (other than literally shipping a VM). So setting up a dev env is one problem, but deploying it so that the prod env is the same and works the same is another.

Re: My Python Development Environment, 2020 Edition

#185

Post by coldtea » Tue, Nov 12, 2019, 12:30 PM UTC

roel_v wrote: post #181

coldtea wrote: post #168

Earlier quoted context omitted.

Note how you only use one version of Python above, which is not the case discussed.

Until now I just deal with that by always explicitly specifying the whole path to the python executable. Granted my needs are very run-of-the-mill, but wouldn't that suffice for many people? I've tried several times over the last few months to get into all this python environment/package stuff, but it all feels like yak shaving... much like the hours and hours I spend customizing vim years ago, which were fun (at tha…

>Granted my needs are very run-of-the-mill, but wouldn't that suffice for many people?

For individual people perhaps. For companies with older projects, newer projects, greenfield stuff, etc, no.

Re: My Python Development Environment, 2020 Edition

#186

Post by ownagefool » Tue, Nov 12, 2019, 12:35 PM UTC

kstenerud wrote: post #169

marmada wrote: post #31

Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…

The alternative is an opinionated build system defined by the language developers. Like any dictatorship, that can be fine if those in charge are benevolent and competent. For programming languages, the first is almost always true, but the second is far from guaranteed. Skill at programming language development has no bearing on skill at developing a build, packaging, and distribution system. Go is a prime example of…

The thing is, Golang and Python had the same problem with regards to depenencies, in that they punted on the problem and the community came up with several competing products that confused users.

Re: My Python Development Environment, 2020 Edition

#187

Post by thesuperbigfrog » Tue, Nov 12, 2019, 12:41 PM UTC

int_19h wrote: post #117

thesuperbigfrog wrote: post #86

Earlier quoted context omitted.

You can have multiple JVMs or JDKs installed, and therefore the need to change environment variables depending on your use cases, but I was referring to Java being part of the operating system in the same way that Python is part of some operating systems, for example several Linux distributions (Fedora, RHEL, and practically all derivatives).

Isn't it still just a package on Red Hat distros? A base system package, granted, because some system tools are written in Python. But in any case, it just becomes one more version of Python to consider. If you're already dealing with multiple versions, what difference does it make?

It is "just a package" in the sense that there are RPMs for Python, but many system management tools are Python scripts that assume you have Python and specific Python libraries installed so that everything will run correctly.

If you have root privileges and you run "sudo pip" commands you might accidentally break the specific Python dependencies that the system scripts rely on. See https://developers.redhat.com/blog/2018/11/14/python-in-rhel...

There's no issue with using the system Python, but any Python packages should be installed via yum or similar Red Hat / Fedora tools and not pip.

Note that the newer versions of RHEL have created developer-specific tool packages to separate the system packages from developer packages. This allows the developer packages to get upgraded quickly so developers have nee, shiny tools without breaking the compatibility that the base system needs to keep running.

Re: My Python Development Environment, 2020 Edition

#188

Post by globular-toast » Tue, Nov 12, 2019, 12:45 PM UTC

marmada wrote: post #31

Does anyone else think this reflects badly on Python? The fact that the author has to use a bunch of different tools to manage Python versions/projects is intimidating. I don't say this out of negativity for the sake of negativity. Earlier today, I was trying to resurrect an old Python project that was using pipenv. "pipenv install" gave me an error about accepting 1 argument, but 3 were provided. Then I switched to…

No. Using an ensemble of tools is in the tradition of Unix. I much prefer using small tools that do one thing and do it well.

Re: My Python Development Environment, 2020 Edition

#189

Post by globular-toast » Tue, Nov 12, 2019, 12:57 PM UTC

Evidlo wrote: post #37

For those new or unfamiliar with python, I think the best solution is the simplest: pip and virtualenv

Yes, definitely. But other tools can be used in addition to solve their own problems.

Need to have multiple versions of python installed and easily accessible? Use pyenv.

Need to run tests across multiple versions of python? Use tox.

Need to freeze environments for deployment purposes? Use pip-tools.

Need to freeze the entire operating system? Use docker or vagrant.

Don't use tools you don't need. That would be silly.

Re: My Python Development Environment, 2020 Edition

#190

Post by globular-toast » Tue, Nov 12, 2019, 12:59 PM UTC

snorkasaurus wrote: post #22

I like pip-tools for venv requirements management, but I don't see it mentioned much.

I use pip-tools. It fits in nicely as an additional component to the standard toolset (pip and virtualenv). But most people probably do not need to freeze environments so it's great to be able to not use it for most projects.