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

Running get-pip in an environment with no pip installed gives "requirement already satisfied" #19

Closed
pfmoore opened this issue Apr 14, 2018 · 2 comments
Closed

Running get-pip in an environment with no pip installed gives "requirement already satisfied" #19

pfmoore opened this issue Apr 14, 2018 · 2 comments

Comments

@pfmoore
Copy link
Member

pfmoore commented Apr 14, 2018 

>python .\get-pip.py
Requirement already up-to-date: pip in c:\users\gustav\appdata\local\temp\tmpg92v1j4j\pip.zip (10.0.0)
Collecting setuptools
  Using cached setuptools-39.0.1-py2.py3-none-any.whl
Collecting wheel
  Using cached wheel-0.31.0-py2.py3-none-any.whl
Installing collected packages: setuptools, wheel
Successfully installed setuptools-39.0.1 wheel-0.31.0

Using --force-reinstall works around this.
@pfmoore pfmoore mentioned this issue Apr 14, 2018
Closed
@evgenymarkov
Copy link

It breaks my custom docker image with python today :(

@alex alex mentioned this issue Apr 14, 2018
Closed
@njsmith njsmith mentioned this issue Apr 15, 2018
Merged
@fake-name fake-name mentioned this issue Apr 15, 2018
Closed
fake-name added a commit to fake-name/AutoTriever that referenced this issue Apr 15, 2018
@fake-name
Fix more pip issues. See pypa/pip#5220 pypa/get-pip#19 pypa/get-pip#20
b445f41
@dstufft dstufft mentioned this issue Apr 15, 2018
Merged
@dstufft
Copy link
Member

dstufft commented Apr 15, 2018

As of ba67ea6 this should be fixed, it can take some time for the various automation machinery to pull in the updated get-pip.py so that it's updated and fixed at bootstrap.pypa.io/get-pip.py.

dolang added a commit to dolang/manylinux that referenced this issue Apr 16, 2018
@dolang
Merge upstream changes (4a20e4b); remove get-pip hack
55f670c 
- Incorporated the lastest changes from the official repository.
  - That cleanup removed two packages from 'yum erase ...' which looks
    like an oversight. Readded.
- Removed the hack which fixed the broken build when the new pip was
  released.  This has been fixed upstream, see here:
  pypa/get-pip#19
@dolang dolang mentioned this issue Apr 16, 2018
Closed
trishankatdatadog pushed a commit to pypa/manylinux that referenced this issue Apr 10, 2019
@mayeut @trishankatdatadog
[WIP] Manylinux2010 (#279)
749d394 
* Minimal usable merge of markrwilliams:manylinux2 into current pypa:master

- The dockerfiles build successfully.
- Compared to current master, there's a new intermediate image for
  glibc.  As the x86_64 build depends on it, this must have a predefined
  name.  In the PR the "naming prefix" is 'markrwilliams/manylinux2',
  therefore it's assumed for all images.
- There's a problem with libcurl which has been (temporarily) resolved
  with script which redirects yum.  See docker/build_scripts/build.sh for
  details.

The following script is proven to work:

  pushd docker/glibc/
  docker build -t markrwilliams/manylinux2:centos-6.9-no-vsyscall
  popd
  docker/build_scripts/prefetch.sh curl openssl
  docker build -t markrwilliams/manylinux2:x86_64 \
    -f docker/Dockerfile-x86_64 docker/
  docker build -t markrwilliams/manylinux2:i686 \
    -f docker/Dockerfile-i686 docker/

* Clean-up and adjustments for manylinux2010

- docker/build_scripts/build.sh:
  - removed libncurses.devel; not part of PEP 571
  - removed gpg as dependency, because yum already requires it
  - removed some /dev/null redirections, because they hinder debugging

- docker/build_scripts/manylinux1-check.py
  - renamed to manylinux-check.py
  - changed names/comments to new version
  - the check now targets glibc 2.12 instead of 2.5

- .travis.yml
  - only changed the image name
  - TODO: x86_64 still needs a script for the no-vsyscall image dependency

- docker/deploy.sh
  - changed image name

- note: .rst files have not been touched

* Fix for new release of pip (v10.0.0) breaking the build script

- The freshly released version of pip breaks build_utils.sh which tries
  to get the latest and greatest.  Added a condition to instead use the
  latest version below v10.

* Merge upstream changes (4a20e4b); remove get-pip hack

- Incorporated the lastest changes from the official repository.
  - That cleanup removed two packages from 'yum erase ...' which looks
    like an oversight. Readded.
- Removed the hack which fixed the broken build when the new pip was
  released.  This has been fixed upstream, see here:
  pypa/get-pip#19

* Re-add the two /dev/null redirections in build.sh

* Merge upstream changes (6f3bc0b)

* Merge upstream changes (3dd4551)

* Merge upstream changes (4132165)

* Adapt build.sh for the x86_64 two-stage build

- Add platform-dependent clause
- Assign the same prefix to the the no-vsyscall image (quay.io/pypa/...)
- The dependent docker/Dockerfile-x86_64 needs this prefix in FROM ...

* Getting Travis to play along

- Increase in `travis_wait` time
- Shunting build output off into a log file which can be inspected
  on failure.

* Drop 32-bit support and upgrade to devtoolset-7

* Update README.rst

manylinux2 -> manylinux2010

* Add comment regarding MANYLINUX2010_DEPS

* Add comment for Software collection & EPEL usage

* Move expat-devel to PYTHON_COMPILE_DEPS

* Use local gpgkey for RPM-GPG-KEY-CentOS-6

* Update to devtoolset-8

* Replace travis wait by custom command

Prevent stdout timeout. The global travis timeout is the only one to apply now.

* Use travis-ci build stages and cache glibc build

glibc patch is unlikely to change very often, use travis-ci cache mechanism in order not to rebuild it every time.

also, use build stages so that when it does change, glibc build is run as a pre-step, it will probably help not reaching the time limit, or at least, glibc build will be cached for job restart.
grzanka pushed a commit to grzanka/manylinux that referenced this issue May 20, 2020
@mayeut @grzanka
[WIP] Manylinux2010 (pypa#279)
81d1b03 
* Minimal usable merge of markrwilliams:manylinux2 into current pypa:master

- The dockerfiles build successfully.
- Compared to current master, there's a new intermediate image for
  glibc.  As the x86_64 build depends on it, this must have a predefined
  name.  In the PR the "naming prefix" is 'markrwilliams/manylinux2',
  therefore it's assumed for all images.
- There's a problem with libcurl which has been (temporarily) resolved
  with script which redirects yum.  See docker/build_scripts/build.sh for
  details.

The following script is proven to work:

  pushd docker/glibc/
  docker build -t markrwilliams/manylinux2:centos-6.9-no-vsyscall
  popd
  docker/build_scripts/prefetch.sh curl openssl
  docker build -t markrwilliams/manylinux2:x86_64 \
    -f docker/Dockerfile-x86_64 docker/
  docker build -t markrwilliams/manylinux2:i686 \
    -f docker/Dockerfile-i686 docker/

* Clean-up and adjustments for manylinux2010

- docker/build_scripts/build.sh:
  - removed libncurses.devel; not part of PEP 571
  - removed gpg as dependency, because yum already requires it
  - removed some /dev/null redirections, because they hinder debugging

- docker/build_scripts/manylinux1-check.py
  - renamed to manylinux-check.py
  - changed names/comments to new version
  - the check now targets glibc 2.12 instead of 2.5

- .travis.yml
  - only changed the image name
  - TODO: x86_64 still needs a script for the no-vsyscall image dependency

- docker/deploy.sh
  - changed image name

- note: .rst files have not been touched

* Fix for new release of pip (v10.0.0) breaking the build script

- The freshly released version of pip breaks build_utils.sh which tries
  to get the latest and greatest.  Added a condition to instead use the
  latest version below v10.

* Merge upstream changes (4a20e4b); remove get-pip hack

- Incorporated the lastest changes from the official repository.
  - That cleanup removed two packages from 'yum erase ...' which looks
    like an oversight. Readded.
- Removed the hack which fixed the broken build when the new pip was
  released.  This has been fixed upstream, see here:
  pypa/get-pip#19

* Re-add the two /dev/null redirections in build.sh

* Merge upstream changes (6f3bc0b)

* Merge upstream changes (3dd4551)

* Merge upstream changes (4132165)

* Adapt build.sh for the x86_64 two-stage build

- Add platform-dependent clause
- Assign the same prefix to the the no-vsyscall image (quay.io/pypa/...)
- The dependent docker/Dockerfile-x86_64 needs this prefix in FROM ...

* Getting Travis to play along

- Increase in `travis_wait` time
- Shunting build output off into a log file which can be inspected
  on failure.

* Drop 32-bit support and upgrade to devtoolset-7

* Update README.rst

manylinux2 -> manylinux2010

* Add comment regarding MANYLINUX2010_DEPS

* Add comment for Software collection & EPEL usage

* Move expat-devel to PYTHON_COMPILE_DEPS

* Use local gpgkey for RPM-GPG-KEY-CentOS-6

* Update to devtoolset-8

* Replace travis wait by custom command

Prevent stdout timeout. The global travis timeout is the only one to apply now.

* Use travis-ci build stages and cache glibc build

glibc patch is unlikely to change very often, use travis-ci cache mechanism in order not to rebuild it every time.

also, use build stages so that when it does change, glibc build is run as a pre-step, it will probably help not reaching the time limit, or at least, glibc build will be cached for job restart.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@dstufft @pfmoore @evgenymarkov