Pipenv: promises a lot, delivers very little • Hacker News Board

Re: Pipenv: promises a lot, delivers very little

#101

Post by ATsch » Thu, Dec 06, 2018, 1:10 AM UTC

scrollaway wrote: post #80

sametmax wrote: post #68

Earlier quoted context omitted.

I'm very glad we have the wheel and ensurepip now. Yet, I think PyPA has not been taking the best decisions regarding Python packaging. Your Kenneth story is not the only "weird event" in their history. E.G: Did you know that we don't need "pyproject.toml" at all ? That there is already a production ready plain text standard to replace setup.py ? Did you know that this standard has been perfectly working for TWO YEAR…

I love setup.cfg, I've used it for years and indeed pyproject.toml is useless given that setup.cfg has existed for frickin ever at this point (and is supported by a multitude of tools). TOML is nice but its support isn't even in the stdlib which makes it very awkward to use for a core file like that. Here are some examples of my libs/apps using it in the real world, if someone needs references for how to use setup.cf…

I don't understand the pyproject.toml hate. pyproject.toml exists specifically so you can specify your build system. Without it, you are basically forced to use setuptools/distutils as is currently the case. Hence, pyproject.toml and setup.cfg aren't at all in conflict.

Re: Pipenv: promises a lot, delivers very little

#102

Post by cellularmitosis » Thu, Dec 06, 2018, 1:10 AM UTC

https://github.com/pypa/pipenv/issues/1382

^ This was just such a glaringly terrible design decision, and the fact that they won't even acknowledge it as being a mistake is really frustrating.

npm already found the best solution (if ./node_modules exists, it is automatically used -- no need to run any sort of shell commands). All they had to do was just copy their behavior.

Oh well, maybe the _next_ python virtual environment tool will get it right... :(

Python is a great technology but it is really a shame that is hampered by bad decisions (e.g. the 2->3 fiasco).

Re: Pipenv: promises a lot, delivers very little

#103

Post by cellularmitosis » Thu, Dec 06, 2018, 1:14 AM UTC

rendaw wrote: post #43

greysteil wrote: post #26

Earlier quoted context omitted.

Sometimes, improvements don't happen in a straight line. There's been a lot of work on Pipenv over the the last 6 months, predominantly by Dan Ryan and Tzu-Ping Chung, and it's getting stronger and stronger with each release. If you've gone back to using pip I'd encourage you to give Pipenv another try. Introducing a lockfile is a big step forward for Python dependency management, and the team working on Pipenv are c…

Pipenv tries to upgrade all the versions of everything in your lockfile whenever you add a new package (not just dependencies of the package), and there's no way to disable this behavior. Right now. That's the tip of the iceberg.

Poor control over this sort of behavior makes Cocoapods very frustrating to deal with.

Re: Pipenv: promises a lot, delivers very little

#104

Post by joshuamorton » Thu, Dec 06, 2018, 1:15 AM UTC

cellularmitosis wrote: post #102

https://github.com/pypa/pipenv/issues/1382 ^ This was just such a glaringly terrible design decision, and the fact that they won't even acknowledge it as being a mistake is really frustrating. npm already found the best solution (if ./node_modules exists, it is automatically used -- no need to run any sort of shell commands). All they had to do was just copy their behavior. Oh well, maybe the _next_ python virtual en…

The behavior you describe is great until you run `py.test myproject` and it proceeds to invoke all of the unit tests for tensorflow or whatever.

Re: Pipenv: promises a lot, delivers very little

#105

Post by androidgirl » Thu, Dec 06, 2018, 1:17 AM UTC

umvi wrote: post #54

I hate python package/dependency/virtualenv management so much. Even JavaScript is preferable. I find npm very easy to wrap my head around. I do npm install ___ and it does a lookup in its repository and downloads it and its dependencies to node_modules. If I want to start fresh, I simply delete node_modules. Everything else "just works" when I invoke node myapp.js. Punto e basta. pipenv masquarades as the same thing…

See, I feel like python has a lot of those benefits and the package management doesn't need to be so complex.

Seriously, python package management can be fairly simple. On most of our machines at work, it's just "virtualenv .env && source .env/bin/activate". Then you install your packages and... everything is in one directory, like node_modules in javascript.

A clean reinstall is easy from there: remove the .env and just repeat.

I feel like pipenv violates KISS, and that a more traditional virtualenv/venv/pyenv setup is the way to go.

Re: Pipenv: promises a lot, delivers very little

#106

Post by scrollaway » Thu, Dec 06, 2018, 1:26 AM UTC

ATsch wrote: post #101

scrollaway wrote: post #80

Earlier quoted context omitted.

I love setup.cfg, I've used it for years and indeed pyproject.toml is useless given that setup.cfg has existed for frickin ever at this point (and is supported by a multitude of tools). TOML is nice but its support isn't even in the stdlib which makes it very awkward to use for a core file like that. Here are some examples of my libs/apps using it in the real world, if someone needs references for how to use setup.cf…

I don't understand the pyproject.toml hate. pyproject.toml exists specifically so you can specify your build system. Without it, you are basically forced to use setuptools/distutils as is currently the case. Hence, pyproject.toml and setup.cfg aren't at all in conflict.

They're not in conflict. The problem is pyproject.toml is superfluous. See my comment here: https://news.ycombinator.com/item?id=18614058

Re: Pipenv: promises a lot, delivers very little

#107

Post by scrollaway » Thu, Dec 06, 2018, 1:28 AM UTC

joshuamorton wrote: post #104

cellularmitosis wrote: post #102

https://github.com/pypa/pipenv/issues/1382 ^ This was just such a glaringly terrible design decision, and the fact that they won't even acknowledge it as being a mistake is really frustrating. npm already found the best solution (if ./node_modules exists, it is automatically used -- no need to run any sort of shell commands). All they had to do was just copy their behavior. Oh well, maybe the _next_ python virtual en…

The behavior you describe is great until you run `py.test myproject` and it proceeds to invoke all of the unit tests for tensorflow or whatever.

That's absolutely the sort of thing that can be fixed in pytest's test discovery algorithm. It's not like this isn't exactly the same fix as in the js world (= ignore node_modules in test discovery).

Re: Pipenv: promises a lot, delivers very little

#108

Post by joshuamorton » Thu, Dec 06, 2018, 1:33 AM UTC

scrollaway wrote: post #107

joshuamorton wrote: post #104

Earlier quoted context omitted.

The behavior you describe is great until you run `py.test myproject` and it proceeds to invoke all of the unit tests for tensorflow or whatever.

That's absolutely the sort of thing that can be fixed in pytest's test discovery algorithm. It's not like this isn't exactly the same fix as in the js world (= ignore node_modules in test discovery).

Sure but then you have a chicken/egg problem: pytest isn't the only testing library that does test discovery (standard library unittest does too, among tons of other 3p ones). Does everyone follow pipenv's convention? Do you write a PEP? What's the solution (maybe a pep-like is the right one to be honest), but its not an immediate change, and makes people less likely to use your tool in the interim.

Kenneth used a growth hack.

Re: Pipenv: promises a lot, delivers very little

#109

Post by sametmax » Thu, Dec 06, 2018, 1:39 AM UTC

ATsch wrote: post #101

scrollaway wrote: post #80

Earlier quoted context omitted.

I love setup.cfg, I've used it for years and indeed pyproject.toml is useless given that setup.cfg has existed for frickin ever at this point (and is supported by a multitude of tools). TOML is nice but its support isn't even in the stdlib which makes it very awkward to use for a core file like that. Here are some examples of my libs/apps using it in the real world, if someone needs references for how to use setup.cf…

I don't understand the pyproject.toml hate. pyproject.toml exists specifically so you can specify your build system. Without it, you are basically forced to use setuptools/distutils as is currently the case. Hence, pyproject.toml and setup.cfg aren't at all in conflict.

- there is nothing you can do with pyproject.toml that you can't with setup.cfg. E.G: you are not forced to use setuptools to use setup.cfg. Any tool supporting pyproject.toml could support setup.cfg as easily, since it's a documented plain text format. It's a political decision.

- there are things you can't do with pyproject.toml you can with setup.cfg. E.G: you can't use pyproject.toml with legacy tools, or with just a fresh python setup. This may change in the future, but would requires a lot of effort because changing setuptools is a very tedious process.

- resources (time, people, money, documentation, public attention, communication, etc) invested in creating and supporting pyproject.toml could be invested in improving setup.cfg and its ecosystem support. E.G: Why does poetry support pyproject.toml and not setup.cfg ? No technical reason. Why does nobody knows this easy way to package python libs ? No technical reason reason either.

So not only the new format brings nothing on the table, but it is also a setback, AND add clutter to a situation that was just begining to be solved. It's not just poor engineering, it's poor manners really.

I've been coding in Python for 15 years. I've lived this: https://stackoverflow.com/a/14753678

Stop the pain.

Re: Pipenv: promises a lot, delivers very little

#110

Post by paultopia » Thu, Dec 06, 2018, 1:50 AM UTC

I like and use pipenv, but the lockfile slowness thing is truly a nightmare. It's especially bad in the data science stack. On my fast MBP, I can `pipenv install numpy pandas matplotlib` and then go get lunch, and there's a fairly good chance it won't be done when I get back.