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.

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

--no-clean and --build are broken #2060

Closed
gwideman opened this issue Sep 23, 2014 · 7 comments

Comments

Projects
None yet
2 participants
@gwideman
Copy link

commented Sep 23, 2014

Pip version 1.5.6
Python 3.4
Windows 7-64

pip install help advertises options:

--no-clean to prevent pip from deleting the build directory and contents, and
-b (--build) to specify build directory

and the help for -b says "The default in a virtualenv is "[venv path]/build". The default for global installs is "[OS temp dir]/pip_build_[username]".

On Windows, and from a virtual env, when I run:

pip install -b [some existing path] --no-clean [somepackage].whl

... pip actually uses C:/Users/[me]/AppData/Local/Temp/pip-[random]-build/[packagename] as the build directory, and deletes it when done.

So:

--no-clean is broken
-b (--build) is broken
--build's help text about default build path seems to be incorrect.

From my not-too-thorough inspection, the problem appears to be that the code that deterimines build path and clean behavior is in req.py, and ignores the no_clean and build_dir settings. Code in install.py that does pay attention to no_clean and build_dir is pre-empted.

I'm assuming that some refactoring of the code broke these features.

I realize that build_dir and no_clean are deprecated (and pip shows a message to that effect), but if they are broken then they should not be reported as deprecated.

Further, issue #906 discusses this deprecation, in which a number of users request that no_clean NOT be removed. I add my vote to that, as it's useful for troubleshooting build steps that went wrong. The current issue that I'm raising is a case in point!

@qwcode

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2014

it's not broke in linux (using v1.5.6):

can you provide full console output to a gist or a pastebin somewhere that confirms what you're saying.

@qwcode

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2014

[somepackage].whl

oh, ok, if you're installing directly from a local archive, then you're problem may be #804

@qwcode

This comment has been minimized.

Copy link
Contributor

commented Sep 24, 2014

btw, it looks like #804 may be fixed for local wheel archives in the develop branch (i.e. it's not released yet) as a by-product of #1831. I'll re-confirm tomorrow and update the issues and changelog if true.

@gwideman

This comment has been minimized.

Copy link
Author

commented Sep 24, 2014

@qwcode Looks like you figured out what I was reporting, and perhaps it's fixed.
I guess the issue is that for local archives, pip expects to get the project name from inside the archive once it's unpacked into the build directory, hence does not have the project name in time to name the build directory. Hence reverts to temp build directory.
However, with wheel archive, the project name is in the archive name, so pip could get the project name from there.
Also, even if it uses the temp build directory, there's no rationale for --no-clean to be ignored.
Anyhow, sounds like some or all of this is resolved in the develop branch.
Thanks for commenting.

@qwcode

This comment has been minimized.

Copy link
Contributor

commented Sep 25, 2014

with wheel archive, the project name is in the archive name, so pip could get the project name

right, and it does now in develop branch (PR #1831)

even if it uses the temp build directory, there's no rationale for --no-clean to be ignored

agreed, will add a comment about that to #804

@qwcode

This comment has been minimized.

Copy link
Contributor

commented Sep 25, 2014

updated the changelog about #1831 fixing this problem for wheel archives
3bb4cbd

@gwideman

This comment has been minimized.

Copy link
Author

commented Sep 25, 2014

@qwcode Thanks Marcus!

vbraun added a commit to vbraun/sage that referenced this issue Sep 24, 2016

Trac #21480: Make sagelib setup.py self-contained and independent of …
…SAGE_ROOT

This ticket changes the build process of sagelib in the following way:
 - `src/Makefile` delegates ALL building to `src/setup.py`
 - `src/setup.py` no longer depends on environment variables
`$SAGE_ROOT`, `$SAGE_SRC`, `$SAGE_DOC_SRC` etc. (to demonstrate this,
`Makefile` poisons these environment variables). It still depends on
`$SAGE_LOCAL` and environment variables that point below it.

This ticket is meant as:
 - preparation for VPATH builds of sage-the-distribution (#21469)
 - working towards the goal of making `sagelib` pip-installable -- see
#21507 for the eventual goal of having sagelib on PyPI
 - making the flow of directory information at build time clearer for
developers

 More specifically, the goal of this ticket is that only SAGE_LOCAL
needs to be set when the user does 'pip install' of the sagelib. (This
ticket almost achieves this, except it also needs SAGE_PKGS and
SAGE_CYTHONIZED to be set. The hope is that #20382 and other future
tickets will develop better mechanisms to communicate package and
directory information to the build.)

. . . . . . .

Some possibly useful information:
 - Documentation on distutils (https://docs.python.org/2/install/),
describing use of `--build-base` to do VPATH builds.
 - `pip install` keeps the source directory clean, building instead in a
temporary directory, by copying the sources.
 `pip install` also offers options `--build` to select a build
directory, but there are some pip issues:
[pypa/pip#2060 2060],
[pypa/pip#2053 2053],
[pypa/pip#804 804] that affect this
 - #14807 has some tricks to making VPATH builds work without copying
all python source files. But it uses automake instead of setup.py; we
will not do this in our ticket.

URL: https://trac.sagemath.org/21480
Reported by: mkoeppe
Ticket author(s): Matthias Koeppe
Reviewer(s): Jeroen Demeyer

vbraun added a commit to vbraun/sage that referenced this issue Oct 11, 2016

Trac #21480: Make sagelib setup.py self-contained and independent of …
…SAGE_ROOT

This ticket changes the build process of sagelib in the following way:
 - `src/Makefile` delegates ALL building to `src/setup.py`
 - `src/setup.py` no longer depends on environment variables
`$SAGE_ROOT`, `$SAGE_SRC`, `$SAGE_DOC_SRC` etc. (to demonstrate this,
`Makefile` poisons these environment variables). It still depends on
`$SAGE_LOCAL` and environment variables that point below it.

This ticket is meant as:
 - preparation for VPATH builds of sage-the-distribution (#21469)
 - working towards the goal of making `sagelib` pip-installable -- see
#21507 for the eventual goal of having sagelib on PyPI
 - making the flow of directory information at build time clearer for
developers

 More specifically, the goal of this ticket is that only SAGE_LOCAL
needs to be set when the user does 'pip install' of the sagelib. (This
ticket almost achieves this, except it also needs SAGE_PKGS and
SAGE_CYTHONIZED to be set. The hope is that #20382 and other future
tickets will develop better mechanisms to communicate package and
directory information to the build.)

. . . . . . .

Some possibly useful information:
 - Documentation on distutils (https://docs.python.org/2/install/),
describing use of `--build-base` to do VPATH builds.
 - `pip install` keeps the source directory clean, building instead in a
temporary directory, by copying the sources.
 `pip install` also offers options `--build` to select a build
directory, but there are some pip issues:
[pypa/pip#2060 2060],
[pypa/pip#2053 2053],
[pypa/pip#804 804] that affect this
 - #14807 has some tricks to making VPATH builds work without copying
all python source files. But it uses automake instead of setup.sh; we
will not do this in our ticket.

'''configure tarball''':
http://sage.ugent.be/www/jdemeyer/sage/configure-185.tar.gz

URL: https://trac.sagemath.org/21480
Reported by: mkoeppe
Ticket author(s): Matthias Koeppe
Reviewer(s): Jeroen Demeyer

@lock lock bot added the S: auto-locked 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.
You can’t perform that action at this time.