Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

My Python Development Environment, 2020 Edition

jacobian.org

Post reply on HN
Print view View original

141–150 of 241 posts

Re: My Python Development Environment, 2020 Edition

#141

Post by nurettin »

Twirrim wrote: post #82
madelyn wrote: post #39

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 t…

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'…

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?

Re: My Python Development Environment, 2020 Edition

#142

Post by a3n »

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…

It occurs to me that, with respect to version dependency, you can think of Python and Java programming as similar to Smalltalk programming: you program and alter the environment.

In Smalltalk you change parts of the environment. In Python, Java (and Ruby?), you change the entire environment, as described in TFA.

https://www.quora.com/What-is-the-essence-of-Smalltalk

Re: My Python Development Environment, 2020 Edition

#143

Post by j88439h84 »

lone_haxx0r wrote: post #32
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…

Yes. As someone who has never dove deep into python, but has had some contact with it: the package manager ecosystem is the #1 thing keeping me away from it. npm sucks and all, but at least it just works and doesn't get in my way as much.

Poetry does all that stuff, as discussed in the article.

Re: My Python Development Environment, 2020 Edition

#146

Post by [deleted] »

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…

[deleted]

Re: My Python Development Environment, 2020 Edition

#147

Post by tanilama »

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…

Old virtualenv works. Pip works.

This post reads most to me as fad. It is an opinion, you would most likely bail out.

Re: My Python Development Environment, 2020 Edition

#148

Post by fock »

thesuperbigfrog wrote: post #54
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 think it really comes down to Python not having a chosen way to handle package management as well as Python being dependent on the underlying C libraries and compilers for the given platform. Since Python did not prescribe a way to handle it the community has invented multiple competing ways to solve the problem, most of which have shortcomings in one way or another. To further add to the confusion, most Linux and…

I'm not sure how people manage to "foul up" their system python, but you are doing something extremely wrong, when giving random devtools root access to transform a typical (non NixOS and friends) production environment (your workstation!) into a custom development environment.

Given that: are you sure problems arise around pure python-packages (which generally have a well enough forward compatibility), or is the problem with all the cool "machine-code"-embedded packages (which are a lot!)? And yeah, these might indeed break randomly, when installed on different systems of different time-periods. But that's a problem all binary packages have!

Re: My Python Development Environment, 2020 Edition

#149

Post by fock »

dmurray wrote: post #63
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…

For me the biggest problem is C-based python modules that can't just be installed in your virtual environment but want to be part of the global installation. Tkinter and mpi4py are the most recent ones I've had this problem with. I expect someone will tell me "it's trivial to install these in a venv, just do X", but X is not obvious to me.

it's trivial to install C-programs with the appropriate tools such as Nix and spack. You might end up in Tcl-hell in your new python-environment, but as it's not that widely used anymore, one should be fine.

Having said that: you generally want this packages integrated with your system (which provides a self-consistent Tcl as well as MPI-environment)

Re: My Python Development Environment, 2020 Edition

#150

Post by fock »

pvg wrote: post #105
madelyn wrote: post #39

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 t…

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…

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)

Post reply on HN