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

Re: Pipenv: promises a lot, delivers very little

#201

Post by umvi » Thu, Dec 06, 2018, 5:17 PM UTC

toyg wrote: post #196

umvi wrote: post #194

Earlier quoted context omitted.

> A clean reinstall is easy from there: remove the .env and just repeat. Repeat what, manually doing a bazillion `pip install`? Another nice thing about npm is the packages.json file it creates. This allows us to simply add that to version control and then all the new dev has to do is clone and run `npm install` which reads packages.json and installs everything inside of it. I'm sure there's a way to do it in python…

> [exit bash to clear environment] Wat? just deactivate before you rm. Please do not talk about things you clearly don't know well enough (which is patently the case if you can't rememer freeze and deactivate). > Out-of-the-box cognitive burden is several times greater You got any stats on that, or is it just your opinion? Because to me, the completely counter-intuitive --save parameter is much more painful to rememb…

> Wat? just deactivate before you rm.

Ok sure, but starting clean is still a 2 step process (deactivate, remove)

> Please do not talk about things you clearly don't know well enough (which is patently the case if you can't remember freeze and deactivate).

Yes, I openly admit I do not know python's package management/virtualenv stuff well enough. And I don't care to learn either, because I don't use it enough for the investment to be worth it. My point still stands that for each javascript package management task that needs accomplished, you need 2-3x as many commands to accomplish the same thing in python.

> You got any stats on that, or is it just your opinion?

My opinion, of course, but shared by the dozens of people who upvoted my OP.

> Because to me, the completely counter-intuitive --save parameter is much more painful to remember.

In what way is --save counter-intuitive? If anything pip freeze is counter intuitive. How does it know what to save? Does it just save everything you've ever installed? What if you don't want to save everything, just a few of them?

Also, --save and --save-dev allow you to segregate developer dependencies from production dependencies. Is there a way to do that with python? Again, just a guess, but it's probably going to be an unintuitive 3-4 step process that I'll no doubt find on stack overflow.

Re: Pipenv: promises a lot, delivers very little

#202

Post by LyndsySimon » Thu, Dec 06, 2018, 5:18 PM UTC

Townley wrote: post #19

Curious about one criticism in particular: I can run pipenv shell to get a new shell which runs the activate script by default, giving you the worst of both worlds when it comes to virtualenv activation: the unwieldiness of a new shell, and the activate script, which the proponents of the shell spawning dislike. In a project that just uses pip + a virtual environment, I'm used to activating the virtual environment wh…

> What do "proponents of shell spawning" dislike about the activate command?

For me, it modifies my existing shell in ways that I don't fully understand. While I've never had any issues with that, I have experienced similar problems in the past with RVM and they were incredibly difficult to debug.

Using the OS's tooling to create an isolated environment seems to fit much better with the "Unix philosophy" than modifying the existing one.

Re: Pipenv: promises a lot, delivers very little

#203

Post by pas » Thu, Dec 06, 2018, 5:20 PM UTC

GauntletWizard wrote: post #137

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…

I already managed my python deps with a lockfile - requirements.txt and requirements-frozen.txt, which about three lines of shell script took care of for me. From the article, it doesn't sound like pipenv buys me much on top of that.

It's a "standard" way to do those scripts. It gives you the NodeJS + NPM way's "npm i", by creating a virtualenv and pip installing into it. It helps with specifying prod and dev dependencies too - if I remember correctly.

Re: Pipenv: promises a lot, delivers very little

#204

Post by RayDonnelly » Thu, Dec 06, 2018, 6:21 PM UTC

azag0 wrote: post #176

beagle3 wrote: post #167

Earlier quoted context omitted.

As you have experience with pyenv, pipenv and poetry, you might be able to answer: Why not conda? I've been using conda since ~4 years now, and every single complaint lodged against any of the other package managers was never an issue with conda in the first place. And yet, it seems like there's a SEP field around it and people just ignore its existence? In this thread, for the first time, I've seen someone mention t…

Because publishing a package on PyPI is trivial compared to publishing on the Anaconda cloud. For the latter, you need to build your package for every platform and Python version you want to support. So sou need to setup some CI. This is just such an overkill for a pure-Python package. It makes a lot of sense for a project with a nontrivial C extension though, and I do build a conda package for one such project of mi…

There's no such requirement at all, but it's a noble goal and one every package developer should strive for.

Re: Pipenv: promises a lot, delivers very little

#205

Post by Nullabillity » Thu, Dec 06, 2018, 8:04 PM UTC

RayDonnelly wrote: post #160

Nullabillity wrote: post #138

Earlier quoted context omitted.

> The only non-system package manager that provides Python and its own toolchains - for Linux and macOS presently - which are used to compile every C, C++ and Fortran package, including Python itself is conda and the Anaconda Distribution. Nix[0] is also perfectly usable without NixOS, and provides all of that, but has far more non-Python libraries and applications packaged. It's also not constantly trying to sell yo…

Great I'll try it out, I always meant to but never got round to it. Does it work on macOS or Windows yet? What's the oldest Linux distro upon which it will run? Not sure we constantly try to sell our Enterprise product. You could look at it less cynically as we sell an Enterprise product to allow us to provide the Anaconda Distribution for free.

> Does it work on macOS or Windows yet?

It runs fine on macOS. It works on WSL if you disable SQLite's write-ahead log (`echo "use-sqlite-wal = false" > /etc/nix/nix.conf` before installing), but it's much slower than running it on native Linux.

> What's the oldest Linux distro upon which it will run?

It brings its own libraries, so the primary question would be what kernel you use. I haven't verified any specific version, but you'll probably be fine. You might need to disable sandboxing though, since that makes pretty elaborate use of the various namespace systems.

Re: Pipenv: promises a lot, delivers very little

#206

Post by Kwpolska » Thu, Dec 06, 2018, 8:31 PM UTC

sametmax wrote: post #179

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…

Because I hate the "this ship has sailed" argument about pyproject.toml, here are some github usage stats: - setup.py: 1,259,007 results ( https://github.com/search?q=filename%3Asetup.py ) - setup.cfg: 165,716 results ( https://github.com/search?q=filename%3Asetup.cfg ) - pyproject.toml: 2,137 results ( https://github.com/search?q=filename%3Apyproject.toml ) Also, remember that setup.cfg is completly compatible with…

setup.cfg isn't always used as a setup.py replacement. I use it for configuring flake8, wheel, pytest and coverage: https://github.com/Kwpolska/python-project-template/blob/mas...

Re: Pipenv: promises a lot, delivers very little

#207

Post by Kwpolska » Thu, Dec 06, 2018, 8:50 PM UTC

cyberpanther wrote: post #60

pipenv is not perfect but it is definitely headed in the right direction. It is a lot easier for beginners to get started with which is one of the best things I've found. To address one of the problems, Running Scripts: basic complaint is you are starting a new shell always and you have to prefix all commands. Prefixing commands sucks but you can get around it pretty easy with an alias. alias pr="pipenv run" alias dm…

Aliases are not really a solution here. They will just clutter your shell config and could potentially end up shadowing existing commands.

Re: Pipenv: promises a lot, delivers very little

#208

Post by EdwardDiego » Thu, Dec 06, 2018, 8:51 PM UTC

ric2b wrote: post #181

EdwardDiego wrote: post #140

Earlier quoted context omitted.

We don't need lockfiles in Java land because we generally use version ranges very carefully and rely on package developers following semver - and we certainly don't use "just whatever the latest release is, dude" like shown in the example Pipfile: https://pipenv.readthedocs.io/en/latest/basics/#example-pipf... (the asterisks) I get why Python needs lockfiles, but goddamn, that need is a symptom of the mess of managin…

> We don't need lockfiles in Java land because we generally use version ranges very carefully Yes, which is part of the reason why lots of Java projects almost never update their dependencies, because no one remembers why that version was chosen. Splitting what you want from what you have is important to communicate this. > There's still a long way to go - I use Airflow for ETL management, and I'm using pipenv to man…

Enforce Flask-wtf 0.8 and see if it works.

Re: Pipenv: promises a lot, delivers very little

#209

Post by pseudalopex » Thu, Dec 06, 2018, 10:10 PM UTC

sametmax wrote: post #150

pseudalopex wrote: post #133

Earlier quoted context omitted.

The format of setup.cfg is whatever configparser accepts, which is different in different versions of Python.

First, it managed to work fine for setuptools for 2 years accross all recent python versions. That's because the differences are minor and edge cases. Try to use pyproject.toml in most CI toolchain just for fun... Second, the format of setup.cfg is defined in a documentation already, so there is a reference outside of configparser. Yes, the low level format is not explicitly defined (although it is implicitly): so le…

Using pyproject.toml just requires a recent version of pip. Which CI tools can't handle that?

I wouldn't call comments an edge case. The distutils documentation has a definition for comments, but I think it actually just uses configparser. setuptools just uses configparser. The pbr documentation has a slightly different definition, but I wouldn't be surprised if it just uses configparser too.

They also have different definitions of non-string types.

Even if you call those edge cases, do you think a PEP that turned edge cases into silent errors would be approved?

Re: Pipenv: promises a lot, delivers very little

#210

Post by toyg » Thu, Dec 06, 2018, 10:30 PM UTC

umvi wrote: post #201

toyg wrote: post #196

Earlier quoted context omitted.

> [exit bash to clear environment] Wat? just deactivate before you rm. Please do not talk about things you clearly don't know well enough (which is patently the case if you can't rememer freeze and deactivate). > Out-of-the-box cognitive burden is several times greater You got any stats on that, or is it just your opinion? Because to me, the completely counter-intuitive --save parameter is much more painful to rememb…

> Wat? just deactivate before you rm. Ok sure, but starting clean is still a 2 step process (deactivate, remove) > Please do not talk about things you clearly don't know well enough (which is patently the case if you can't remember freeze and deactivate). Yes, I openly admit I do not know python's package management/virtualenv stuff well enough. And I don't care to learn either, because I don't use it enough for the…

> Yes, I openly admit I do not know python's package management/virtualenv stuff well enough.

And still, you are here trying to measure the length of your "commands" with others' "commands".

> My opinion, of course, but shared by the dozens of people who upvoted my OP.

Ah great, engineering by acclamation. That usually ends well. That's how we got pipenv, btw: a popular developer stood up and declared "I'll fix it!", to general acclaim from the Powers That Be... and then things broke harder, and here we are.

> for each javascript package management task that needs accomplished you need 2-3x as many

That's precisely the perspective that led us to the mess that is pipenv: "npm is the model, we should all be like npm". Except npm fundamentally serves only a few specific needs, and was built on the lawless prairies of an ecosystem with limited aims, no stdlib, and without 28 years of accumulated legacy practices; whereas python has been pulled in every direction for literally decades, and now has to herd all that legacy into something more coherent, slowly (because this or that constituency will be ready to scream about breaking compatibility, as we've just had to endure for about 10 years with py3) and correctly - to avoid ending up in situations like the periodic breakage that happens in npm because this or that package has misbehaved.

> In what way is --save counter-intuitive?

"I've already told you to install, why should I repeat the concept? Are you really so dumb a 'manager' that you would ignore what you just installed?"

And btw, Stack Overflow says --save is actually obsolete since 2013 at least [1], so it looks like you don't know npm very well either. Maybe we should just give up and build an AI that learns development from SO, and find ourselves more meaningful jobs.

[1] https://stackoverflow.com/questions/19578796/what-is-the-sav...