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

181–190 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#181

Post by ric2b »

EdwardDiego wrote: post #140
bobbyi_settv wrote: post #94

Earlier quoted context omitted.

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…

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 manage it - except Pipenv can't create a lockfile because a dependency of a dependency of Airflow requires in flask-wtf I'm not sure what you expect it would be able to do here...

Re: Pipenv: promises a lot, delivers very little

#182

Post by beagle3 »

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…

Are you aware that Conda fully supports and integrates pip?

Publish on PyPI, it's just as usable in Conda to everyone.

But assuming you for some reason insist on publishing to the system you use - the vast majority of users don't ever publish a package; what's stopping them from using Conda?

I admit I have never tried to publish anything on the Anaconda cloud, but I'm a bit surprised - I was under the impression that publishing pure python packages is simple; The requirement to do it for different python versions, though, seems perfectly warranted to me - and indeed, I ran into issues with packages on PyPI not working on specific versions (but nowhere listed as such).

Re: Pipenv: promises a lot, delivers very little

#183

Post by [deleted] »

pseudalopex wrote: post #133
sametmax wrote: post #109

Earlier quoted context omitted.

- 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 ju…

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

[deleted]

Re: Pipenv: promises a lot, delivers very little

#184

Post by orf »

beagle3 wrote: post #167
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…

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…

Conda has no lockfile. The management commands are horrible to use and inconsistent. The "pip integration" is just "produce a requirements.txt and install it", so unless you're using some conda only dependency (thankfully those are few and far between) what's the point?

Conda is also annoyingly outside the python ecosystem. It seems to want to replace pip/pypi instead of working with it.

Re: Pipenv: promises a lot, delivers very little

#185

Post by black-tea »

lvh wrote: post #58
black-tea wrote: post #52

Earlier quoted context omitted.

I use pyenv on some distros and it is good, but on Gentoo there is no point because Python is slotted which means you can install multiple versions and have them all available on PATH. I then use virtualenvwrapper and specify the version manually (e.g. -p python3.7). Alternatively you can always do python3.7 -m venv ...). The annoying thing with pip freeze is it doesn't have a concept of a "world" file like emerge (G…

I prefer to keep locally installed Pythons for regular use everywhere, though I guess some distros get the same effect by patching pip to make `--user` the default (and hence pip install xyzzy goes to my home directory instead of messing with something that belongs to the OS). In particular, one way this has bitten me is if the OS expects a certain Python with a certain set of dependencies to be available for systems…

I used to install tools using --user, but now I install all tools using my package manager (emerge) so I don't have to worry about maintaining a ~/bin etc. So I basically never run pip outside of a virtualenv.

Portage is written in python, yes, so you can't just change your system python at will, but that's not a problem really.

Re: Pipenv: promises a lot, delivers very little

#186

Post by guggle »

sametmax wrote: post #68
legostormtroopr wrote: post #4

Pipenv is a really interesting development for Python, and I'm glad that someone was working to improve dependency locking for Python. However, Kenneth abused his position with PyPA (and quickly bumped a what is a beta product to version 18) to imply Pipenv was more stable, more supported and more official than it really was. And worse still, for anyone saying "but ts open source, you get what you pay for", Kenneth a…

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.

Re: Pipenv: promises a lot, delivers very little

#187

Post by guggle »

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.

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)

Re: Pipenv: promises a lot, delivers very little

#188

Post by stochastic_monk »

beagle3 wrote: post #167
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…

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…

That's about as long as I've been using conda. But I avoid it whenever I can because of a variety of gripes. The two biggest are the following:

1. On Lustre file systems, 'Solving environment...' can take minutes. I don't like waiting minutes to provide permission to install packages.

2. A lot of conda packages are broken. It's managed by maintainers, and unfortunately, some people maintaining believe that if it works on their machine, it will work elsewhere. Since I'm tired of ABI and runtime linking errors, I often just install from source.

Re: Pipenv: promises a lot, delivers very little

#189

Post by guyskk »

application and library are very different, it's unrealistic to have one tool solve 99% library problems. If you disagree, please check:

1. Can it support different python version and virtual environment?

2. Can it support build packages for windows,osx,ubuntu,centos...?

3. Can it support different build tools, for example: wheel, cython...?

4. Can it manage dynamic depdency version?

5. Can it manage version, like bumpversion?

Re: Pipenv: promises a lot, delivers very little

#190

Post by sdispater »

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)

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

Post reply on HN