Install-time requirements for pip and conda #577
Conversation
| exit(1) | ||
|
|
||
| proj_includes = proj_includes.split() | ||
| proj_libraries = [] |
There was a problem hiding this comment.
These defaults should take us back to what we had before. i.e. proj_libraries = ['proj']
|
In principle this is great 👍 |
I've still got a week, right... ;) But anyway, I figure we should try and get all the install-related issues squared away with the setuptools changes. |
It didn't take much. Yes, I agree - we're issuing a release candidate (today I hope) for this very reason. |
|
OK, I think that should fix up your comments. |
|
Tests are failing due to an SSL error when accessing binstar. I'm actually seeing the same error on my local machine when I try to upload binstar packages. Anyone have any idea if we can fix this? |
|
@ajdawson several people are experiencing this today. The options are: or |
|
In case you guys are not on the conda mailing list. The latest request update should fix this. |
To keep compatibility with conda, the requirements files for optional packages do not specify install of the defaults. Fixes SciTools#576.
Also, ensure error messages go to stderr.
On Fedora 20, proj 4.8.0 _is_ available, but does not contain the proj.pc file for pkg-config.
QuLogic
force-pushed
the
requirements
branch
from
78da733
to
ca84915
Compare
|
I've rebased to remove the extra edits, and put in some fixes for Python 3. The new build should pull in the updated |
| return proj_version | ||
|
|
||
|
|
||
| conda = os.getenv('CONDA_DEFAULT_ENV') |
There was a problem hiding this comment.
I'm not entirely comfortable with having conda special cases in the setup.py. I'm trying to get my head around what not having proj in pkg-config actually means.
Instead of checking for conda when we can't find the pkg-config information, is it worth seeing if we can find the proj executable, and working from there? After all, proj version can be determined with:
$> proj
Rel. 4.8.0, 6 March 2012
There was a problem hiding this comment.
The conda check is not a fallback; it's an override. The trouble is that conda provides pkg-config files, but does not provide the script, nor does it override the search path.
What this means is, I will find the system install via pkg-config in place of conda's first, and never check proj. That will possibly cause compiling/linking against system proj over conda's (possibly this depends on the full linker path after everything's put together, of course.)
There was a problem hiding this comment.
Probably the more correct fix is to have conda either provide pkg-config or set PKG_CONFIG_PATH.
There was a problem hiding this comment.
But conda does set PATH, so we could check to see if proj == the proj found with pkg-config. I don't know which is preferable though - the one on the PATH or the one defined by pkg-config...
There was a problem hiding this comment.
pkg-config will only give you header and library path, and these are not necessarily easily linked to the binary's path. One might assume bin/include/lib or lib32 or lib64, but really autoconf (used by proj's install) allows you to override any of these.
Install-time requirements for pip and conda
|
Thanks @QuLogic - this is a big change, but I think you've nailed it! I'm going to kick off a build on Windows and keep my fingers crossed... |
This PR adds some checking for dependencies at install time. Specifically,
geos-configprogram.pkg-configor conda.pipandconda, and are also parsed to provide theinstall_requiresandextra_requiresso thatpip installorpython setup.py installwill automatically install dependencies.I cannot test on OS X or Windows; consequently, I have not made failure to find GEOS or Proj4 fatal. If someone can confirm the tests are sufficient for those platforms, then I can do so.
The split between
installandextrasis somewhat arbitrary based on theINSTALLfile. Suggestions are welcome there.