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

221–229 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#221

Post by sametmax »

guggle wrote: post #186
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…

Your latest blog post say good things about poetry and bad things about pyproject.toml. However the default in poetry seems to be pyproject.toml... I'm confused.

Because I'm not dogmatic, I can regognize good tools, even if I disagree with the underlying political decision.

Computing is not black and white, and perfect purity is only nice in "fizz buzz".

Now to be extra fun, poetry uses a custom section ([tool.poetry]) in pyproject.toml, not really the standard itself. What does that say about this format ?

Re: Pipenv: promises a lot, delivers very little

#222

Post by sametmax »

sdispater wrote: post #190
guggle wrote: post #187

Earlier quoted context omitted.

oh, nevermind... I'll stick to manual venv/pip: ptest poetry add requests [UnicodeDecodeError] 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

Author of Poetry here! I've never seen that error before. Which version of Python do you use? And feel free to create an issue on the issue tracker: https://github.com/sdispater/poetry/issues

pyproject debates aside, I love your work. I think poetry is a beautiful piece of software, the source code is very easy to read and the 2/3 compat is well done (although I would not use assert to check things).

Re: Pipenv: promises a lot, delivers very little

#223

Post by umvi »

toyg wrote: post #210
umvi wrote: post #201

Earlier quoted context omitted.

> 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!"…

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

"edited Sep 18 at 18:15"

`5.0.0` was introduced May 25, 2017 [1]. Most linux distributions have not picked it up yet in their repos. Ubuntu 18.04 (released this year) is still on npm 3.5. It's unreasonable to expect a developer to be familiar with the bleeding edge, especially when existing projects are locked into using older versions.

I don't know why you are being so contentious about this. I actually love Python and hate JavaScript. But in my opinion, JavaScript has the superior package management setup which is why I am rooting for PEP 582.

[1] https://github.com/npm/npm/tags?after=v5.0.2

Re: Pipenv: promises a lot, delivers very little

#224

Post by wirrbel »

icebraining wrote: post #71
wirrbel wrote: post #62

Earlier quoted context omitted.

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…

At a previous job, we used an even simpler solution: just download everything to a directory (called "deps") with pip install --target deps -r requirements.txt Then running the application with PYTHONPATH=deps python myapp.py This was also simple to integrate with service supervisors, since most make it easy to configure a environment variable.

If this works for you, good. I think I would be cautious giving this out as advice because you can run into problems this way with regards to different python versions. The activate script uses the python version used to setup the environment.

Re: Pipenv: promises a lot, delivers very little

#225

Post by SmirkingRevenge »

IvanAnishchuk wrote: post #156
rtpg wrote: post #111

Earlier quoted context omitted.

libraries and apps _should_ get different treatment. A library often has to coexist with other unknown code (open world assumption), an application you're controlling is effectively existing in one specific universe: the one you define (closed world assumption). You wouldn't write your application to support 5 versions of Django, but you _probably_ would do so for a library. That said, I do basically agree about `pip…

> We could have built a tool to manipulate `requirements.txt` files There's pip-compile from https://pypi.org/project/pip-tools/ that does exactly that. Pipenv uses its resolving mechanism if I'm not mistaken. It produces standard req.txt file with versions pinned and supports separate dev requirements. It had some bug with upgrades last time I checked though, not sure whether it's resolved, currently considering usi…

Have used pip-tools for a long time... its very uncomplicated and just makes things pretty darn simple.

Since its all just requirements files with pip-tools, its been fairly commitment free, in that I haven't had to substantially rework any major bits of workflow to use it - nor would I to remove it. Not sure I could say the same thing about pipenv and/or poetry.

Re: Pipenv: promises a lot, delivers very little

#226

Post by depressedpanda »

grumps wrote: post #28

I rarely comment here on hackernews. I've also seen several flame wars over pipenv. I also believe that python packaging and pinning is nothing but a mess. Recently I started using Pipenv and suddenly I've been having horrific issues with python to the point of me almost giving up on the language itself. I believe the issue is a mix of Pipenv, Pip and Debian. I don't have full scope view of the issue yet but without…

Why are you having issues with Debian and pip?

- First of all, never `sudo pip install` anything.

- Second, on a fresh Debian install, run `sudo apt install python3-pip && pip3 install --user --upgrade` to get the latest pip while still allowing Debian to use its old outdated version. I would actually recommend you remove it to prevent you from accidentally using with (with `sudo apt purge python3-pip`), unless you need it available at the system level for some reason.

- Add `~/.local/bin` to your $PATH.

- If you need to deal with py2 packages for some reason, consider managing multiple Python versions with pyenv[1].

I won't go into Pipenv because I dislike the tool.

[1]: https://github.com/pyenv/pyenv

Re: Pipenv: promises a lot, delivers very little

#227

Post by vqrs »

pmoriarty wrote: post #11
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…

"I was sorely disappointed with pipenv" Can you flesh this out a little bit? What in particular were you disappointed with pipenv? How does poetry do a better job?

I just tried poetry because of this thread. So I can't really talk about poetry, but I can share my frustration with pipenv.

First, the best thing I like about pipenv is `pipenv shell`. It's integration with virtualenvs is really good and a joy to use.

I think the CLI usage is really confusing. Every time I wanted to do something, I googled what the correct way was and often found github issues about stuff I was struggling with.

I don't think the defaults are intuitive, it's not clear when pipenv actually touches the lock file, when it just reinstalls everything and likes to make me wait 10 minutes. I don't understand why `pipenv install something` will also often also touch unrelated packages, why `pipenv install` even changes the lock file. Yes, I learned that I'm supposed to use `pipenv sync`, but whose idea was that? It's not even mentioned in the basic concepts, so maybe I still misunderstood something?

When I found poetry because of this thread, it was like someone had read my mind: https://github.com/sdispater/poetry#what-about-pipenv

I had hope when I found this: https://github.com/pypa/pipenv/issues/1463#issuecomment-3677... but my use of pipenv this past month was still very frustrating. Also, I don't really see how I can use pipenv on windows and on linux for the same project when the OS is stored inside the lock file.

Re: Pipenv: promises a lot, delivers very little

#228

Post by hynek »

chatmasta wrote: post #192
j88439h84 wrote: post #131

Earlier quoted context omitted.

`pip-compile --generate-hashes` is the best way to manage python dependencies. https://github.com/jazzband/pip-tools https://gist.github.com/hynek/5e85706cee589a204251b333595853...

Could those hashes be different for the same package built on different architectures?

Yes, that’s why there’s multiple hashes per package.

Re: Pipenv: promises a lot, delivers very little

#229

Post by agateau »

guggle wrote: post #187
guggle wrote: post #186

Earlier quoted context omitted.

Your latest blog post say good things about poetry and bad things about pyproject.toml. However the default in poetry seems to be pyproject.toml... I'm confused.

oh, nevermind... I'll stick to manual venv/pip: ptest poetry add requests [UnicodeDecodeError] 'ascii' codec can't decode byte 0xc3 in position 1: ordinal not in range(128)

Looks like a locale problem. `locale-gen en_US.UTF-8` should fix it.
Post reply on HN