Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

pip install -r requirements.txt doesn't know when package installation fails during native compilation #2

Closed
michaelkirk opened this issue Mar 13, 2011 · 2 comments
Closed

pip install -r requirements.txt doesn't know when package installation fails during native compilation #2

michaelkirk opened this issue Mar 13, 2011 · 2 comments
Labels
auto-locked Outdated issues that have been locked by automation type: bug A confirmed bug or unintended behavior

Comments

@michaelkirk
Copy link

pip install -r requirements.txt failed on a few packages on the first run (because I didn't have some required headers for some native compilation requirements).

After installing the proper headers, I'd like to rerun "pip install -r requirements.txt" and any packages who's installation wasn't complete would retry.

Instead I had to manually specify

pip install "PackageName"
@ogirardot
Copy link
Contributor

hi, any way to reproduce this ?

@carljm
Copy link
Contributor

carljm commented Dec 12, 2011

Closing until we get adequate repro instructions.

@carljm carljm closed this as completed Dec 12, 2011
@qwcode qwcode mentioned this issue Sep 26, 2012
Closed
@qwcode qwcode mentioned this issue Oct 30, 2012
Closed
@qwcode qwcode mentioned this issue Jun 11, 2013
Closed
@dstufft dstufft mentioned this issue Jul 18, 2013
Closed
@qwcode qwcode mentioned this issue Jul 28, 2013
Closed
@qwcode qwcode mentioned this issue Sep 17, 2013
Closed
@qwcode qwcode mentioned this issue Oct 21, 2013
Closed
@qwcode qwcode mentioned this issue Dec 31, 2013
Closed
@qwcode qwcode mentioned this issue Jan 10, 2014
Closed
@qwcode qwcode mentioned this issue Feb 2, 2014
Closed
@qwcode qwcode mentioned this issue Mar 3, 2014
Merged
@tonyarkles tonyarkles mentioned this issue Mar 6, 2014
Closed
@qwcode qwcode mentioned this issue Mar 17, 2014
Closed
@qwcode qwcode mentioned this issue Aug 17, 2014
Closed
@msabramo msabramo mentioned this issue Mar 5, 2015
Merged
msabramo added a commit to msabramo/pip that referenced this issue Mar 6, 2015
@msabramo
install: Less output on success; once on failure
c1d21e3 
This fixes 2 aspects of `pip install output`:

1. When `pip install` succeeds, it's still printing a lot of output from
   the package's setup.py. The average consumer of Python packages, when
   they do `pip install lxml`, probably doesn't care to see a bunch of
   output about:

   - copying files to a `build` directory
   - installing and running Cython
   - compiling C code

   This is noise to most when the `pip install` succeeds. It's useful to
   see all the output when the install fails, which is the subject of pypa#2
   below. On success, the output is now very clean with 5 short lines:

       $ pip install lxml
       Collecting lxml
         Using cached lxml-3.4.2.tar.gz
       Installing collected packages: lxml
         Running setup.py install for lxml
       Successfully installed lxml-3.4.2

2. When there's an error from `pip install`, it's annoying to have to
   scroll through 2 different copies of the failure output (especially when
   one is filtered and one is unfiltered so one might have stuff that the
   other doesn't). This makes it not print the filtered version so that
   there is just the unfiltered version and nothing is repeated.

       $ pip install ~/dev/git-repos/lxml
       Processing /Users/marca/dev/git-repos/lxml
       Installing collected packages: lxml
         Running setup.py install for lxml
           Complete output from command ...
           cc -c /var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.c -o var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.o
           /var/folders/gw/w0clrs515zx9x_55zgtpv4mm0000gp/T/xmlCheckVersion4tBaVV.c:1:10: fatal error: 'libxml/xmlversion.h' file not found
           #include "libxml/xmlversion.h"
                    ^
           1 error generated.
           ----------------------------------------
           Command "/Users/marca/python/virtualenvs/pip/bin/python -c ...

   None of the lines above are repeated.
@msabramo msabramo mentioned this issue Mar 8, 2015
Closed
qwcode added a commit that referenced this issue Apr 23, 2015
@qwcode
refactor the requirements file parsing
764e468 
two major changes:

1) re-use the optparse options in pip.cmdoptions instead of maintaining
   a custom parser

2) as a result of #1, simplify the call stack
    from:  parse_requirements -> parse_content -> parse_line
      to:  parse_requirements -> process_line

beyond #1/#2, minor cosmetics and adjusting the tests to match
@qwcode qwcode mentioned this issue Jul 17, 2015
Closed
@qwcode qwcode mentioned this issue Sep 23, 2015
Closed
natefoo added a commit to natefoo/pip that referenced this issue Oct 13, 2015
@natefoo
1. Provide a fallback mechanism for determining ABI flags if config vars
63d239f 
   are unavailable, but issue a warning if this is used.
2. Explicitly handle the case where the unicode detection finds wide
   unicode but this is a 3.3+ build (necessary due to #1)
3. Fix tests broken due to pypa#2.
@qwcode qwcode mentioned this issue Oct 21, 2015
Closed
@ghost ghost mentioned this issue May 20, 2017
Closed
@jdemeyer jdemeyer mentioned this issue Aug 17, 2017
Closed
trishankatdatadog pushed a commit to DataDog/pip that referenced this issue Feb 25, 2019
@truthbk
Merge pull request pypa#2 from DataDog/jaime/fixlog
e251116 
[pip] fix paths + logging defaults
@lock lock bot added the auto-locked Outdated issues that have been locked by automation label Jun 5, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Jun 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
auto-locked Outdated issues that have been locked by automation type: bug A confirmed bug or unintended behavior
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@carljm @michaelkirk @ogirardot