11 ms·

> why do I need to call a flag to install requirements? Because pip is used extensively as a manual command to install something - you don't expect something l

> why do I need to call a flag to install requirements? Because pip is used extensively as a manual command to install something - you don't expect something like DIR or ls to automatically get its list of files to list from a DIR.txt or a ls.txt file, do you?

yladiz 10y ago
Can you call pip install by itself?
- fredsir 10y ago
  No, and I think it would be great to be able to just call `pip install` and have it use the pipfile if available.
  - scarygliders 10y ago
    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..."
    - Senji 10y ago
      Just have an env var that's off by default. Name it $piparanoia
    - yladiz 10y ago
      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.
      - marcosdumay 10y ago
        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.
        lukeschlather 10y ago
        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.
        xapata 10y ago
        > 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.
        lukeschlather 10y ago
        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.
        10y ago
    - vacri 10y ago
      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...
      - shadowmint 10y ago
        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.
        olau 10y ago
        "... 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.
  - ncouture 10y ago
    One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful. “The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.” Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand. “I don't understand you!” said the programmer. Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window. “What are you trying to tell me?” asked the programmer. Master Foo pointed at the programmer's head. Then he pointed at a rock. “Why can't you make yourself clear?” demanded the programmer. Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan. As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him. At that moment, the programmer achieved enlightenment. --Master Foo Discourses on the Graphical User Interface
    - seanp2k2 10y ago
      More: http://catb.org/esr/writings/unix-koans/gui-programmer.html http://catb.org/esr/writings/unix-koans/gui-programmer.html Thanks, I laughed.
  - rat87 10y ago
    Maybe pip build
amelius 10y ago
> Why are the requirements like function calls though? Flexibility?
- scrollaway 10y ago
  You lose flexibility if you can't parse or modify the file with a known parser (TOML, JSON)
  - amelius 10y ago
    You should parse the file by running it.
    - scrollaway 10y ago
      I'd expect any developer worth their salt to know why that's a bad idea - or are we still parsing json using eval()?
    - piqufoh 10y ago
      That sounds like a terrible idea - especially if you don't know if you can trust the source of the file.
      - dismantlethesun 10y ago
        Installation files by default are run. If you have a normal Python module sitting on PyPi, and install it it may run a setup.py which could potentially do anything that your currently active user is allowed to do. Adding custom programming logic into the requirements' file isn't really an issue, when setup.py could already grab a C compiler and start binding in system libraries into its package.
        scrollaway 10y ago
        You're missing the forest for the trees. My point was that you're losing flexibility when you're not able to parse/generate a data-driven file using a well-known data format. And unless you're using a homoiconic format, code is not (easily) parsable as data.
antihero 10y ago
Well ls without arguments lists the most relevant thing, ie the files in the current directly. So it would follow that tools do their thing based on the current directory, as specified by package.json/Makefile/Gulpfile/Dockerfile/Vagrantfile et all.

yladiz 10y ago

Can you call pip install by itself?

fredsir 10y ago
No, and I think it would be great to be able to just call `pip install` and have it use the pipfile if available.
- scarygliders 10y ago
  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..."
  - Senji 10y ago
    Just have an env var that's off by default. Name it $piparanoia
  - yladiz 10y ago
    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.
    - marcosdumay 10y ago
      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.
      - lukeschlather 10y ago
        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.
        xapata 10y ago
        > 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.
        lukeschlather 10y ago
        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.
        10y ago
  - vacri 10y ago
    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...
    - shadowmint 10y ago
      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.
      - olau 10y ago
        "... 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.
- ncouture 10y ago
  One evening, Master Foo and Nubi attended a gathering of programmers who had met to learn from each other. One of the programmers asked Nubi to what school he and his master belonged. Upon being told they were followers of the Great Way of Unix, the programmer grew scornful. “The command-line tools of Unix are crude and backward,” he scoffed. “Modern, properly designed operating systems do everything through a graphical user interface.” Master Foo said nothing, but pointed at the moon. A nearby dog began to bark at the master's hand. “I don't understand you!” said the programmer. Master Foo remained silent, and pointed at an image of the Buddha. Then he pointed at a window. “What are you trying to tell me?” asked the programmer. Master Foo pointed at the programmer's head. Then he pointed at a rock. “Why can't you make yourself clear?” demanded the programmer. Master Foo frowned thoughtfully, tapped the programmer twice on the nose, and dropped him in a nearby trashcan. As the programmer was attempting to extricate himself from the garbage, the dog wandered over and piddled on him. At that moment, the programmer achieved enlightenment. --Master Foo Discourses on the Graphical User Interface
  - seanp2k2 10y ago
    More: http://catb.org/esr/writings/unix-koans/gui-programmer.html http://catb.org/esr/writings/unix-koans/gui-programmer.html Thanks, I laughed.
- rat87 10y ago
  Maybe pip build

amelius 10y ago

> Why are the requirements like function calls though? Flexibility?

scrollaway 10y ago
You lose flexibility if you can't parse or modify the file with a known parser (TOML, JSON)
- amelius 10y ago
  You should parse the file by running it.
  - scrollaway 10y ago
    I'd expect any developer worth their salt to know why that's a bad idea - or are we still parsing json using eval()?
  - piqufoh 10y ago
    That sounds like a terrible idea - especially if you don't know if you can trust the source of the file.
    - dismantlethesun 10y ago
      Installation files by default are run. If you have a normal Python module sitting on PyPi, and install it it may run a setup.py which could potentially do anything that your currently active user is allowed to do. Adding custom programming logic into the requirements' file isn't really an issue, when setup.py could already grab a C compiler and start binding in system libraries into its package.
      - scrollaway 10y ago
        You're missing the forest for the trees. My point was that you're losing flexibility when you're not able to parse/generate a data-driven file using a well-known data format. And unless you're using a homoiconic format, code is not (easily) parsable as data.

antihero 10y ago

Well ls without arguments lists the most relevant thing, ie the files in the current directly. So it would follow that tools do their thing based on the current directory, as specified by package.json/Makefile/Gulpfile/Dockerfile/Vagrantfile et all.