Hacker News Reader

Comment by scarygliders | Hacker News Reader

I disagree - explicit is better than implicit.

What if one intended to type "pip install pillow" but got as far as "pip install " and unintentionally hit <Return> ?

Oh but there's a requirements.txt file sitting right there and "awwww heck now pip is reading it in and installing everything in there.. all I wanted was this new package not listed in that requirements.txt file..."

View on HN

Sure that happens, but is it worth the hassle of having to type -p or -r requirements.txt every time you want to install the requirements for your project? Following that dogma without regard for the reality of what actually works better is silly. It's not always the case that doing what everyone else does is good, but it seems the consensus is have sensible defaults.

This is a similar argument to what happened when Babel in JS land decided to not have anything happen by default and explicitly require you to decide your configuration. It's silly to force users to do something that could be solved by a sensible default, and this is a clear case where a sensible default is appropriate.

I agree that explicit is better than implicit. Especially in this case. You can create an alias pipr='pip install -r requirements.txt' or similar if you find that fits your needs better.

Especially for newcomers, an implicit "use Pipfile if exists, else requirements.txt" is just unnecessary magic.

`pip install` should only be for the default way that projects define dependencies, where the default is the way. Were we to have both pipfile, and requirements.txt, and maybe a third, and a fourth option, I don't think `pip install` should work.

I also don't think it's ever a good idea to have multiple options for something like that.

Is it so much trouble? How often do you type 'pip install -r requirements.txt' outside of a script?

Personally, I'm in the "whatever" camp. But you can be certain that such a change will break something.

For me it's more about encouraging good behavior. While it's common to pip install random packages, that should really be the exception rather than the rule. Usually you should make a project, add some packages, and run `pip install`.

Right now, the whole system encourages you to build bespoke environments that are really difficult to replicate. Making the default use requirements.txt encourages you to write down everything you're doing in a reproducible way.

> write down everything you're doing in a reproducible way

Making `pip install` context-sensitive (dependent on the current working directory) would reduce reproducibility. Imagine the instructions to a beginner: (1) download, (2) cd, (3) pip install. Many times the beginner will skip step 2 or accidentally wind up in the wrong directory.

I really think the average beginner is not somebody who knows nothing about packaging, but someone like me who knows a lot about other packaging systems. When I started with pip a few months ago, everything was confusing, largely because pip has confusing conventions that don't match tools like bundler, cargo, and npm that I'm more familiar with.

I do think you're misrepresenting the instructions to the beginner. The instructions to the beginner are (1) download (2) cd (3) run tox.

Beginners shouldn't even need to know what pip is, tox (or another build tool) should handle everything for you.

> The average beginner is ... someone like me

When I say "beginner" I mean someone who is learning their first programming language and may have never opened Terminal or `cmd.exe` before.

> run tox

I thought the argument above was that the command should be `pip install`. This is confusing.

> Beginners shouldn't even need to know what pip is

Ok, in that case, why do you care whether `pip install` has an implicit default mode?

My preference would be that pip install only has one mode. Realistically, there is going to be backwards compatibility stuff, but ideally, even in advanced use you should never have a reason to use anything other than pip install, and the rest should be specified in config files.

You could write a make file that does the install. That'd solve the one-command desire.

The hassle of typing three characters? Yes it is worth the hassle of not accidentally installing things that aren't specified.

Dear god we love to bikeshed.

It's not bike shedding, it's a valid concern: either I type it infrequently enough that I will probably forget, meaning I'll have to either remember after I type it incorrectly the first time or look on Google, or I type it frequently enough that it actually does affect my productivity. In my eyes, having no default and forcing users to type in something like -r requirements.txt or -p is just forcing users to do something that can be sensibly defaulted and wasting their time. It's like in an elevator, are you expected to close the door by pressing the close door button every time, or open the door when you arrive to the floor? No, because the elevator manufacturer knows getting in an elevator and pressing a floor button means you want the door to close and open for you. The same can be said about pip install: if a requirements file (requirements.txt, Pipfile) exists, and the user types in pip install, it's simple enough to infer that the user wants to install based on the installation file parameters. What's wrong with that inference? Dogma?

An elevator door must always be closed prior to going up or down in a building. Pip will sometimes install from Pipfile, sometimes from requirements, sometimes from another command line argument. What if both Pipfile & requirements.txt exist?

Requiring a user to say what they want from a command line tool (that takes barely two seconds to type) is hardly an exhausting task.

Absolutely. If it does the wrong thing, e.g. by doing that outside a virtualenv, I'd very much prefer it to not destroy my global environment. Or if you have different .txt files for different purposes, I'd rather not destroy the virtualenv by adding / changing packages by accident.

Besides. Tab completion. And if it's really that important, make an `alias pipi="pip install -r requirements.txt"`.

The same thing that happens when you want to remove "#csv" but unintentionally hit <Return> after the "#".[1]

Having pip 'just work' if there's a config file in the current directory would make it behave the same as 'npm install'. I have absolutely no love for npm and the whole node_modules debacle, but neither have I heard of anyone complain of the problem you describe, inadvertently 'npm install'ing instead of 'npm install foo'ing. It's rare enough and easy enough to revert that it's not that much of a problem, IMO.

Of course, if you're going to design a new package manager, you should look at the way OSes do it, not the way language ecosystems do it. OSes are much more battle-tested with their managers, and can't afford to handwave away problems and edge-cases.

[1] HN interprets stars as italic markup, so here are hashes...

I don't think so, not if you're building a language package manager.

I think you should look carefully at what npm and cargo do, and try your best to avoid what os package managers do.

Unfortunately, half the problem with python is that system level package managers want to rule the world, and not allow you to have 'user level' packages (ie. libraries) installed.

pygtk, for example, can't be pip installed. In fact, you can't actually (afaik) even use it from a virtualenv without modifying sys.path.

The most annoying thing about pip for me is that it isn't a 'complete story' in many cases. You have to actually install system level python-foo packages, which are not pinned in any meaningful way, and then hope that your application works.

Repeatable builds should be the goal of a python package manager; and that means being able to install specific versions of python (and c) libraries, in a way that is idempotent to the underlying OS; whatever it is.

OS level package managers solve a different problem; providing a single consistent packaged version of libraries and applications for users; having repeatable builds to generate those packages is a different problem, and, as evidenced by the huge amount of work the debian folk are putting into repeatable builds, not a trivial one; certainly not one that dpkg has already solved.

"... and, as evidenced by the huge amount of work the debian folk are putting into repeatable builds, not a trivial one; certainly not one that dpkg has already solved."

The reproducible builds project in Debian is about reproducing the build and getting every single bit the same. I think that's the primary reason why it's hard - there are various innocent sources of non-determinism, e.g. dictionary ordering in Python (pre 3.6), time stamps, build environment details, etc. If you can settle for just getting a specific repeatable set of versions, I think Debian solved that ages ago, it's just that they don't keep old versions lingering around forever.

By the way, if you take a step back and squint, I wouldn't be so sure OS level package managers really are that different from what what you call language package managers.

I don't think you have to get far back. Package managers are a dime a dozen with very little to distinguish each other. Only reason I know to choose a particular one is always "when in Rome."

Sadly the same for build programs.

Just have an env var that's off by default. Name it $piparanoia

Reply on news.ycombinator.com