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

Pipenv: promises a lot, delivers very little

chriswarrick.com

Post reply on HN
Print view View original

91–100 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#91

Post by emptysea »

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

> Sometimes, improvements don't happen in a straight line. I don't deny that, what I am (and the article is) saying is that we were sold on Pipenv being "the officially recommended Python packaging tool from Python.org". And PyPA didn't refute it, and Heroku didn't refute it, so the community bought it. Yes, introducing a Lockfile is huge, and it was massively needed, and thats why when we were told "heres the offici…

Another reason Heroku didn't refute Pipenv is that Pipenv's creator leads Python related things at Heroku.

Re: Pipenv: promises a lot, delivers very little

#92

Post by chatmasta »

holografix wrote: post #49
avip wrote: post #27

I've long freed myself from the exhausting pipenv/virtualenv/pienv/conda rat-race by using docker. The only downside is some annoying IDEs refuse to acknowledge the existence of interpreter in a container.

can you get VSC code completion to use a python interpreter in a Docker container?

I don’t use VSC, but assuming the interpreter is just a path to an executable file, you could just pass it a script that calls, eg ‘exec docker run -it python’.

Re: Pipenv: promises a lot, delivers very little

#93

Post by jessaustin »

wirrbel wrote: post #62
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…

Basically it seems you are lacking only two shell commands. virtualenv venv . venv/bin/activate Then everything works with pip pip install numpy I actually prefer the pipenv way (or the virtualenvwrapper way) of putting virtualenvs into a dedicated location, so that I can wipe them off the hard disk if I want to free some space. The real interesting and occasionally bothering point on managing your virtualenv is reso…

Those shell commands don't do anything to publish a package, do they? Sorry, python is still lacking quite a bit of what e.g. js with npm has had for years.

Re: Pipenv: promises a lot, delivers very little

#94

Post by bobbyi_settv »

gizmo385 wrote: post #76
scrollaway wrote: post #50

Earlier quoted context omitted.

> It's not suited for libraries and is not designed to be. That's kind of the problem. Why on earth are libraries and apps getting a different treatment? The JS ecosystem manages to have one tool for apps and libraries. One too for installing and publishing. All of it with lockfile support, workspace/"virtualenv" support, etc. And somehow, it's not confusing. Adding one more tool to the stack is a really funky step f…

And it isn't only Javascript that manages to have a single tool for this. Clojure has a single tool. Java has a single tool. Rust has a single tool. This is a solved problem across a variety of popular and mainstream programming languages. I don't mean to suggest that the problem isn't complicated, but this isn't a problem that doesn't have a wealth of previously written solutions to look at for inspiration.

What's the "one tool" for Java? Is it Maven? Ivy? sbt? Gradle? You may say some of those are "build tools" rather than dependency tools, but I don't see how it's different than what we are discussing in Python.

My Java app declares its dependencies in a build.sbt file using Scala syntax and has them cached in an Ivy directory. Yours declares them in a pom file using XML syntax and has them cached in a Maven directory. Neither of us even tries to do lockfiles and instead just has the CI server build an "uber jar" with all the dependencies bundled in.

Re: Pipenv: promises a lot, delivers very little

#96

Post by austinpray »

pseudalopex wrote: post #88
moonsun wrote: post #57

I don't write libraries but pipenv works well for a simple flask application because I don't ask much of it. All I want is a simpler file to look at compared to requirements.txt Here is my guide for newbies like me 1. Use Pipenv in development. 2. Create a requirements.txt each time you make any changes to your pipenv. Commit all three files: pipenv, pipenv lock, and requirements.txt to git. 3. Use this requirements.…

It sounds like pip-tools[1] is what you want Pipenv to be. 1. Put your dependencies in requirements.in. 2. Run pip-compile to generate requirements.txt. 3. Commit both files. 4. Use requirements.txt in production. You can also use setup.py or setup.cfg instead of requirements.in. This lets you build packages and specify dependencies like "Python 3.5+". requirements.in is simpler, though. [1] https://pypi.org/project/…

+1 for piptools. Piptools makes a lot of sense in a docker based workflow (virtualenv not needed).

Re: Pipenv: promises a lot, delivers very little

#97

Post by warmblanket »

emptysea wrote: post #91
legostormtroopr wrote: post #63

Earlier quoted context omitted.

> Sometimes, improvements don't happen in a straight line. I don't deny that, what I am (and the article is) saying is that we were sold on Pipenv being "the officially recommended Python packaging tool from Python.org". And PyPA didn't refute it, and Heroku didn't refute it, so the community bought it. Yes, introducing a Lockfile is huge, and it was massively needed, and thats why when we were told "heres the offici…

Another reason Heroku didn't refute Pipenv is that Pipenv's creator leads Python related things at Heroku.

Not anymore, I don’t believe.

Re: Pipenv: promises a lot, delivers very little

#98

Post by carapace »

dfee wrote: post #2

I was sorely disappointed with pipenv, and transitioned to poetry [1], with which I’ve been very satisfied. There is also some commentary in the README on the design decisions re: pipenv [3]. Contrary to the author's perspective on poetry using poetry-specific sections of pyproject.toml, that's actually the proper implementation (and expected usage) coming out of PEP-518. I also am a big fan of pyenv [3] but that’s o…

> This is the recommended way of installing poetry.

    curl -sSL https://raw.githubusercontent.com/sdispater/poetry/master/get-poetry.py | python
Nope.

Re: Pipenv: promises a lot, delivers very little

#100

Post by flomble »

DonHopkins wrote: post #67

"free (as in freedom)" Isn't that a circular definition, not the official Free Software Foundation line? Is it just a sneaky way of not actually saying "free as in speech"?

It's not circular because "freedom" can't really be used to refer to price (e.g. "freedom of beer"), so it actually disambiguates. I wouldn't personally default to assuming a political motivation for the wording in this case.
Post reply on HN