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

91–100 of 241 posts

Re: My Python Development Environment, 2020 Edition

#91

Post by whateveracct »

behnamoh wrote: post #36
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…

And not just Python, try writing a small script in Haskell or Clojure and you'll see how much burden there is to setup their environments.

Well with Haskell and Clojure, many people just use a pretty plain text editor + a REPL and maybe. And for Haskell at least, that's super easy to install. I suppose there isn't One True Way, but each of the popular options (cabal, Nix+cabal, stack) are only a couple steps.

Haskell with new-style cabal works like a charm with `cabal init` for package setup. And then ghci from there will give you...

- expression evaluation ofc

- type-at-point via type hole annotations

- Laziness inspector via :print

- Breakpoint debugger (someone just posted a nice Reddit text post about it today)

- Package information of terms via :info (and :load $MODULE to get any top-level term in $MODULE into repl scope)

- Docs via :doc (this is pretty new)

- Module export lists via :browse

off the top of my head

Re: My Python Development Environment, 2020 Edition

#92

Post by nerdwaller »

ninetax wrote: post #13

Curious to hear other's experiences with pipenv vs poetry. Has anyone made the switch?

I chose to not use either after trying both. Nether solves understanding `setup.py` (they are just indirections on it). Of the two, poetry seemed more comprehensive and stable across releases. There’s a small cognitive load of knowing a couple of Twine commands if you don’t use either.

Re: My Python Development Environment, 2020 Edition

#93

Post by whateveracct »

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…

This is why I manage every nontrivial project I do nowadays with Nix (Haskell, Go, Python, C & C++, bash ..anything)

Everything is pinned to exact source revisions. You can be relatively sure to be able to git clone and nix-shell and be off to the races.

You can even go the extra mile and provide working editor integration in your nix-shell (especially easy with emacs). So you can enable anyone to git clone, nix-shell, and open a working editor.

The biggest downside is becoming proficient in Nix isn't easy or even straightforward.

Re: My Python Development Environment, 2020 Edition

#94

Post by ryall »

ninetax wrote: post #13

Curious to hear other's experiences with pipenv vs poetry. Has anyone made the switch?

Poetry is amazing, if only for the ability to separate dev and build dependencies. Maybe pipenv does this, but I couldn't get it working well enough to find out.

I've flagged trying to manage python versions on my machine and just develop inside docker containers now (Thanks to VSCode). Using tightly versioned python base images

Re: My Python Development Environment, 2020 Edition

#95

Post by oefrha »

angrygoat wrote: post #79
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 big gap is management of the full dependency tree. With yarn I can get a package.lock which pretty well ensures I'll have the same exact version of everything, with no unexpected changes, every time I run yarn install. I get the same thing in the Rust world with Cargo. In Python it's a mess. Some packages specify their deps in setup.py; some in a requirements file, which may or may not be read in by their setup.p…

I've worked on tons of small to medium-small Python projects over the years where I didn't fix dependency versions at all, not even major versions, just a requirements.txt with a list of package names (usually it's a list of maybe at most ten well-known libraries, resulting in at most twenty actual packages pulled from PyPI). Come back three years later, pull the latest versions of everything, code still works fine.

Now try that with JavaScript or Rust. If you don't fix versions, come back three months later and compatibility is usually fucked up beyond all recognition.

Some languages embraced better dependency locking because they absolutely couldn't not solve the problem.

Re: My Python Development Environment, 2020 Edition

#96

Post by theptip »

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…

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).

Re: My Python Development Environment, 2020 Edition

#97

Post by yjftsjthsd-h »

Daishiman wrote: post #58
ramraj07 wrote: post #51

Earlier quoted context omitted.

Seriously. The author is bending over backwards to accommodate poetry from every direction, from the stupidest installation instructions I've heard, to "can't transfer from requirements.txt" to "it doesn't work well with docker but doable". Like what exactly does it add that's worth all this complexity? Make you a maitai every hour?

Did you even read the article?

https://news.ycombinator.com/newsguidelines.html

> Please don't comment on whether someone read an article. "Did you even read the article? It mentions that" can be shortened to "The article mentions that."

Re: My Python Development Environment, 2020 Edition

#98

Post by yebyen »

packetslave wrote: post #80
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…

To be fair, he says in the article that his requirements are somewhat different from most Python developers, to wit: * "I need to develop against multiple Python versions - various Python 3 versions (3.6, 3.7, 3.8, mostly), PyPy, and occasionally Python 2.7 (less and less often, thankfully)." * "I work on many projects simultaneously, each with different sets of dependencies, so some sort of virtual environment or is…

It's kind of shocking to hear these two quoted as "different than most" requirements – as a Ruby developer, this sounds like exactly a thing that any engineer supporting production systems would need routinely. RVM and bundler are standard developer tools and I would never question the need for supporting multiple versions on the same machine, unless in a very well-defined scenario where RVM was unneeded (like in a containerized environment packaged through a pipeline.)

So sure, there is more than one way to manage a Ruby runtime version, but are there any competitors to Ruby's Bundler? I feel like it's the undisputed champion of Ruby dependency management, working with Rubygems, another unopposed incumbent in its own space, and it never even occurred to me that my language should have more than one of either such tool. Can someone help me understand what drove the Python ecosystem to need more than one dependency manager, ELI5?

I am pretty cloistered as a Ruby developer, but my limited professional experience with other language runtimes tells me that the Ruby "developer environment" experience is really second to none, (change my mind.) Is there any tool which is nearly comparable to Ruby's Pry for Python or other interpreted languages? (I doubt that there is!)

Managing gemsets and multiple versions of Ruby is old-hat.

Re: My Python Development Environment, 2020 Edition

#99

Post by babayega2 »

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 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.

Re: My Python Development Environment, 2020 Edition

#100

Post by abcininin »

kovek wrote: post #70

I'll pay anyone who can assist me with my Python setup. Is there a service like this, where one can find a developer on demand?

I have been using a consistent setup that hasn't yet failed me for the past 2 years.

1. Install Anaconda to your home user directory .

2. create environment using (conda create --name myenv python=3.6) .

3. Switch to the environment using (conda activate myenv) .

4. Use (conda install mypackage), (pip install mypackage) in that priority order .

5. Export environment using (conda env export > conda_env.yaml) .

6. Environment can be created on an other system using (conda env create -f conda_env.yaml) .

Anaconda: https://www.anaconda.com/distribution/#download-section .

Dockerized Anaconda: https://docs.anaconda.com/anaconda/user-guide/tasks/docker/ .

Post reply on HN