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

81–90 of 241 posts

Re: My Python Development Environment, 2020 Edition

#81

Post by yjftsjthsd-h »

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…

> barring JNI

Exactly. It's not Python's only problem, but far and away the most painful snags I've hit with packages is when they use C code, and thereby drag in the whole system. "I'll just `pip install` this- Oh, I need to install foo-dev? Okay, `apt-install foo-dev`... oh, that's in Ubuntu but not Debian? Well this is gonna be fun..." Now I trend a bit more exotic in my systems (NixOS, Termux, *BSD, ...) but if my Python were just Python it would just work so long as I have a working Python install; in practice that's rarely enough.

Re: My Python Development Environment, 2020 Edition

#82

Post by Twirrim »

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't see any strong incentive to change.

Re: My Python Development Environment, 2020 Edition

#83

Post by Twirrim »

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?

I did, certainly don't see what specific value poetry is providing from what he said.

Re: My Python Development Environment, 2020 Edition

#84

Post by ph2082 »

Evidlo wrote: post #37

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

Small python projects I did, I used venv and pip. Learned my lesson through wasting couple of hours after fighting through dependency issues.

Being from JAVA Shop for long time, If I have to switch between different version of JAVA, all I do is change JAVA_HOME to point to correct version, go to base project directory and "mvn clean install" does the job. :).

Re: My Python Development Environment, 2020 Edition

#85

Post by _AzMoo »

Rotareti wrote: post #59
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…

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 versions of apollo, what do I do? Oh right, sure npx for executable isolation so we don't pollute the global namespace.

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

Re: My Python Development Environment, 2020 Edition

#86

Post by thesuperbigfrog »

throwawayjava wrote: post #66
thesuperbigfrog wrote: post #54

Earlier quoted context omitted.

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…

> There is also usually no "system Java", so there is nothing to break along those lines. Oh, but there is :( `jenv shell 1.8` is muscle memory for me now.

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

Re: My Python Development Environment, 2020 Edition

#87

Post by Redoubts »

bocklund wrote: post #41
misnome wrote: post #4

Earlier quoted context omitted.

"Sorry, your dependencies could not be resolved"

Unless there's a bug in the dependency solver, isn't this a good thing? conda is preventing you from installing incompatible packages.

It was bad when it took minutes to figure that out. It has gotten better though.

Re: My Python Development Environment, 2020 Edition

#88

Post by _AzMoo »

thehesiod wrote: post #48
kndjckt wrote: post #17

Earlier quoted context omitted.

I switched from pipenv to poetry over 1 year ago. I love it! The main reasoning was so that I could easily build and publish packages to a private repository and then easily import packages from both pypi and the private repository. Happy to answer more questions.

I'd like to use poetry however ran into https://github.com/sdispater/poetry/issues/1554 We have a custom pypi server and need all requests to go through it, however haven't figured a way to make poetry always use our index server for all modules instead of pypi.org

Add a second source and it will prioritise that over pypi.

  [[tool.poetry.source]]
  name = "my-repo-name"
  url = "https://myrepo.url/"

Re: My Python Development Environment, 2020 Edition

#90

Post by oefrha »

diminoten wrote: post #46

> Governance: the lead of Pipenv was someone with a history of not treating his collaborators well. That gave me some serious concerns about the future of the project, and of my ability to get bugs fixed. Doesn't seem fair. You're not abandoning requests, are you?

Just noticed requests moved from kennethreitz/requests to psf/requests. Interesting.

Edit: From https://www.python.org/psf/github/,

> ... we have created a GitHub organization, @psf, to support and protect projects that have outgrown ownership by their original author.

Post reply on HN