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

211–220 of 229 posts

Re: Pipenv: promises a lot, delivers very little

#211

Post by beagle3 »

stochastic_monk wrote: post #188
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…

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

conda doesn't require you to use conda packages; pip installs are perfectly integrated.

w.r.t lustre - can't comment about that; I prefer local file systems for development for various reasons (most importantly: mmaping huge local files is 10x to 100x more efficient than through networked filing systems).

Re: Pipenv: promises a lot, delivers very little

#212

Post by DonHopkins »

flomble wrote: post #100
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.

Sure it can be used to referred to price: "freedom of cost", thus "free as in beer" -vs- "free as in speech", a common expression you may have heard before, if you are aware of the Free Software Foundation.

https://jamesdixon.wordpress.com/2008/06/04/what-does-free-a...

It's not that it demonstrates a political motivation, just an ignorance of the actual free software culture they're trying to associate themselves with. It's like saying "Make America USA Again". Tautologically circular, close, but no cigar.

Re: Pipenv: promises a lot, delivers very little

#213

Post by pseudalopex »

sametmax wrote: post #151
pseudalopex wrote: post #127

Earlier quoted context omitted.

The "existing standard" is whatever configparser accepts. configparser is part of the standard library. Different versions accept different things. The setuptools documentation covers higher-level things like key names. That isn't what they're trying to standardize. The last sentence you quoted explains why they picked "pyproject" instead of "setup". It isn't why they picked TOML.

See my answer to your other comment. Also "higher-level things like key names" is half of the standard. Besides, picking a new (even if better) serialization format is not good reason to create a whole new standard with names, convention, tooling, etc., as explained earlier. There are sane ways to make the existing system evolves and improves incrementally, using the legacy standards that benefits from the existing s…

Nothing from setuptools is being standardized. Tools can use any keys they want in any format they want in any file they want.

The "legacy standards" are subtly incompatible INI dialects that people recently started putting into the same files. The incompatibilities mostly don't matter because most tools just read their own sections. They do matter if you want to standardize them.

The only new tooling for TOML is a small library. A new INI dialect would need one too.

Re: Pipenv: promises a lot, delivers very little

#214

Post by chatmasta »

Dylan16807 wrote: post #113
chatmasta wrote: post #78

Earlier quoted context omitted.

This doesn’t address his problem of dependencies being “halfway across my computer.”

Yes it does. Everything is installed in the venv folder. To start fresh you just delete it [and restart bash].

That's true, but I assumed GP was referring to the fact that venvs are kept in a global, e.g. $HOME/.venvs, rather than in $(pwd)/.venv like $(pwd)/node_modules.

Re: Pipenv: promises a lot, delivers very little

#215

Post by androidgirl »

umvi wrote: post #194
androidgirl wrote: post #105

Earlier quoted context omitted.

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…

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

Your opinion here is totally valid. Npm has a lot more magic involved than doing stuff by hand with virtualenv.

And yes, aliases and bash scripts help a lot, but do increase initial overhead. I have the entire "delete create install" sequence in an alias as well as activate in another.

But envs are just files, you can even skip activate and just do `.env/bin/python` and it works. That's powerful in a linux shell because now I can just use that environment like a regular executable from anywhere, no global installs required.

I can appreciate preferring something less manual even if I don't! Ultimately, your machine, your code.

Re: Pipenv: promises a lot, delivers very little

#216

Post by [deleted] »

chatmasta wrote: post #214
Dylan16807 wrote: post #113

Earlier quoted context omitted.

Yes it does. Everything is installed in the venv folder. To start fresh you just delete it [and restart bash].

That's true, but I assumed GP was referring to the fact that venvs are kept in a global, e.g. $HOME/.venvs, rather than in $(pwd)/.venv like $(pwd)/node_modules.

[deleted]

Re: Pipenv: promises a lot, delivers very little

#217

Post by Dylan16807 »

chatmasta wrote: post #214
Dylan16807 wrote: post #113

Earlier quoted context omitted.

Yes it does. Everything is installed in the venv folder. To start fresh you just delete it [and restart bash].

That's true, but I assumed GP was referring to the fact that venvs are kept in a global, e.g. $HOME/.venvs, rather than in $(pwd)/.venv like $(pwd)/node_modules.

If you're using the commands in that post, the venv won't be kept in a global location.

Re: Pipenv: promises a lot, delivers very little

#218

Post by sametmax »

pseudalopex wrote: post #209
sametmax wrote: post #150

Earlier quoted context omitted.

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…

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

The most used one in the world: https://github.com/travis-ci/dpl/issues/822

Also the last time I used tox, anything complex didn't work either.

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

Well the current PEP decided to turn a packaging situation that was stable into one that was not, again, after 15 years of mess with many versions of things. So you tell me.

Check the usage stats I posted in an other comment to see the problem.

Besides, yes, we do make compromise on best practices to allow peaceful transition all the time in Python. `async/await` allowing to be a variable silently. Non utf8 defaut encoding argument in open() in windows. Then... we fix it later.

Because I think you conveniently skip a lot of things I wrote in my comments. I clearly state that we would and should consider setup.cfg as a version 1 of the format. Then we would increment on that. I gave a detailed procedure on one way to do that, and there are others.

The point is, all your concerned can be addressed with a progressive transition, starting from setup.cfg. Actually we could even end up with a toml format in setup.cfg, __on the long run__, that matches exactly the current one.

While you addressed non of ours concerns. Just reject them. No will to even recognize there is a problem. It's insulting, really.

We did that during the 2/3 transition. Didn't work so well, did it ?

Re: Pipenv: promises a lot, delivers very little

#219

Post by sametmax »

gvalkov wrote: post #168
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…

> Use it. Talk about it. Write about it. I have a project that converts basic setup.py files to setup.cfg files [1]. Still happily using plain setuptools for library development and pip-tools for application development. [1]: https://github.com/gvalkov/setuptools-py2cfg

Very cool. I'll share that.

Re: Pipenv: promises a lot, delivers very little

#220

Post by sametmax »

pseudalopex wrote: post #213
sametmax wrote: post #151

Earlier quoted context omitted.

See my answer to your other comment. Also "higher-level things like key names" is half of the standard. Besides, picking a new (even if better) serialization format is not good reason to create a whole new standard with names, convention, tooling, etc., as explained earlier. There are sane ways to make the existing system evolves and improves incrementally, using the legacy standards that benefits from the existing s…

Nothing from setuptools is being standardized. Tools can use any keys they want in any format they want in any file they want. The "legacy standards" are subtly incompatible INI dialects that people recently started putting into the same files. The incompatibilities mostly don't matter because most tools just read their own sections. They do matter if you want to standardize them. The only new tooling for TOML is a s…

> Nothing from setuptools is being standardized. Tools can use any keys they want in any format they want in any file they want.

No, if you use any key, it won't work with setuptools.setup(), and just like a python code that doesn't run with cPython will never be popular, it will not be used.

Also, if you look at how poetry use pyproject.tml, they just create a custom section. So basically, they don't use your standard.

> The "legacy standards" are subtly incompatible INI dialects that people recently started putting into the same files. The incompatibilities mostly don't matter because most tools just read their own sections. They do matter if you want to standardize them.

That's kinda my point for comments and comments. Standardize the status quo, then increment from that. Not sexy. Not pure. Welcome to the real life.

Didn't you learn anything from the distutils/distribute/setuptool mess ? From the Python 2 / Python 3 breakage ?

And could you address any of my concerns instead of just attacking ? Because I'm trying to address yours with solutions. You just write short busts of "no, it's bad, we are good". That's not really giving me trust in your decisions, and it __lowers__ my confidence in pyproject.toml because the people defending it basically are not behaving like engineers trying to solve a problem, but as salesmen trying to only defend their product.

> The only new tooling for TOML is a small library. A new INI dialect would need one too.

But but we can start from a standard that works now, is used already, and is compatible with existing stacks. Instead of arriving with the theorical untested, incompatible best thing that add a layer on top of the mess.

Post reply on HN