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

Update install instructions, simplify requirements #1526

Merged
merged 9 commits into from May 29, 2015

Conversation

arve0
Copy link
Contributor

@arve0 arve0 commented May 24, 2015

This tries to simplify the requirements and also updates install instructions. It will most probably not work out of the box. Fixes #1506 (when all errors are ironed out).

I'm open to suggestions!

install_requires=INSTALL_REQUIRES,
requires=REQUIRES,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is used to populate the PyPI entry, which does not pick up install_requires.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'll put it back. Should it hold both runtime and compile dependencies?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd say just runtime.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But please also add a comment since apparently this was a point of confusion. 😄

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It was already commented, but I was to tired to catch it!

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

@blink1073 It's a bit havoc in the code at the time, I'll clean it up when things are starting to look good. Are the numpy.distutils.core.setup required for cython builds?

@blink1073
Copy link
Member

Correct.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Ok, then I will add instructions for those getting scikit-image as source package, and fail more gracefully with instruction for installing scipy, numpy and cython.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Anyone have an idea why the appveyor build does not seem to link cython files correctly?

@blink1073
Copy link
Member

You took Cython out of requirements.txt, try adding a specific [build] install on this line

sed -i 's/networkx>=/networkx==/g' requirements.txt
sed -i '/pillow/d' requirements.txt
else
virtualenv -p python --system-site-packages ~/venv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was needed to make the plot examples work. Right now they're timing out in the 2.7 build.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do you know what was the magic sauce, venv, pillow, scipy or matplotlib?

System pillow and scipy are not meeting the requirements, should we lower the requirements? If the tests pass, I guess this means we require pillow>=1.1.7 and scipy>=0.9.0.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's something in the system site packages (maybe Tk) that was needed to make the matplotlib Template backend work without hanging.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed on the version changes.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Ok, so this is the purposed changes. (I'll clean up the commit noise and Silvester's suggestions later). Note that I'm talking about fresh installs here, neither having runtime or build requirements met.

Changes in skimage

  1. Now requires scipy, numpy and dask[array].
  2. Removed some magic in setup.py.
  3. Gracefully fail when running setup.py and missing numpy.

The effect is that when scikit-image is installed from binaries (read wheel, that is OS X as of now) and setup.py is not ran, dependencies will be correctly installed.

For the source package, it's not the same story, as it will always run setup.py (and fail), never getting to install_requires. Though, if pip are able to run setup.py, it can resolve runtime dependencies (which are overlapping with build dependencies) and build dependencies (setup_requires, a setuptools easy_install directive). So we put build dependencies which do not overlap with runtime dependencies (cython), in setup_requires.

Changes in both test environments

  1. pip now need --trusted-host to install wheels from http

Changes in travis

  1. Test minimum requirements
    • To not tamper with requirements.txt in other cases
  2. Only install binaries from wheel house
    • Let setup.py/install_requires sort out the rest
  3. Do not use venv (if I can get it to pass without)

Changes to appveyor

  1. Do not package bdist_wininst

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Unable to find out when six.moves.urllib was added to six (its above 1.3). Found this: https://bitbucket.org/gutworth/six/pull-request/5/create-sixmovesurllib/diff

Anyone familiar with gitbucket?

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Seems to be 1.4.0

@blink1073
Copy link
Member

@arve0, the reason we want to use our own venv as opposed to the default Travis one is that it kept changing, and breaking our builds. By rolling our own we insulate ourselves from these changes.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Aha. I saw that numpy was already installed in the travis env. I'll use venv for all python version then.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

@jjhelmus Hi! I see you are the creator of the appveyor build, can you help me out? Any idea why the build and wheel install is succeeding but the cython import fails?

https://ci.appveyor.com/project/stefanv/scikit-image-1fxlb/build/1.0.366

Some excerpts:

707

Compiling C:\projects\scikit-image-1fxlb\skimage\_shared\geometry.pyx because it changed.
Cythonizing C:\projects\scikit-image-1fxlb\skimage\_shared\geometry.pyx

794
building extension "skimage._shared.geometry" sources

1323

building 'skimage._shared.geometry' extension
compiling C sources
creating build\temp.win32-2.7
creating build\temp.win32-2.7\Release
creating build\temp.win32-2.7\Release\skimage
creating build\temp.win32-2.7\Release\skimage\_shared
C:\Program Files (x86)\Common Files\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -IC:\Python27_32\lib\site-packages\numpy\core\include -IC:\Python27_32\include -IC:\Python27_32\PC /Tcskimage\_shared\geometry.c /Fobuild\temp.win32-2.7\Release\skimage\_shared\geometry.obj
Found executable C:\Program Files (x86)\Common Files\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe
C:\Python27_32\lib\site-packages\setuptools\dist.py:285: UserWarning: Normalizing '0.12dev' to '0.12.dev0'
  normalized_version,
C:\Program Files (x86)\Common Files\Microsoft\Visual C++ for Python\9.0\VC\Bin\link.exe /DLL /nologo /INCREMENTAL:NO /LIBPATH:C:\Python27_32\libs /LIBPATH:C:\Python27_32\PCbuild /EXPORT:initgeometry build\temp.win32-2.7\Release\skimage\_shared\geometry.obj /OUT:build\lib.win32-2.7\skimage\_shared\geometry.pyd /IMPLIB:build\temp.win32-2.7\Release\skimage\_shared\geometry.lib /MANIFESTFILE:build\temp.win32-2.7\Release\skimage\_shared\geometry.pyd.manifest
Found executable C:\Program Files (x86)\Common Files\Microsoft\Visual C++ for Python\9.0\VC\Bin\link.exe
mt.exe -nologo -manifest build\temp.win32-2.7\Release\skimage\_shared\geometry.pyd.manifest -outputresource:build\lib.win32-2.7\skimage\_shared\geometry.pyd;2

1938
copying build\lib.win32-2.7\skimage\_shared\geometry.pyd -> build\bdist.win32\wheel\scikit_image-0.12.dev0.data\..\skimage\_shared

2247
Failure: ImportError (No module named _shared.geometry) ... ERROR

2336

======================================================================
ERROR: Failure: ImportError (No module named _shared.geometry)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "C:\Python27_32\lib\site-packages\nose\loader.py", line 420, in loadTestsFromName
    addr.filename, addr.module)
  File "C:\Python27_32\lib\site-packages\nose\importer.py", line 47, in importFromPath
    return self.importFromDir(dir_path, fqname)
  File "C:\Python27_32\lib\site-packages\nose\importer.py", line 94, in importFromDir
    mod = load_module(part_fqname, fh, filename, desc)
  File "C:\Python27_32\lib\site-packages\skimage\draw\__init__.py", line 1, in <module>
    from .draw import circle, ellipse, set_color
  File "C:\Python27_32\lib\site-packages\skimage\draw\draw.py", line 3, in <module>
    from ._draw import _coords_inside_image
  File "_draw.pyx", line 1, in init skimage.draw._draw (skimage\draw\_draw.c:23754)
ImportError: No module named _shared.geometry

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Seems like files in build\temp.win32-2.7 are never copied to build\bdist.win32\wheel

Edit. No, that's not it: mt.exe -nologo -manifest build\temp.win32-2.7\Release\skimage\_shared\geometry.pyd.manifest -outputresource:build\lib.win32-2.7\skimage\_shared\geometry.pyd;2

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Ah, found it at last! Cython is actually compiled from source at appveyor, not using version 20, as you've already noted @blink1073.

@blink1073
Copy link
Member

Great progress so far @arve0, thanks for persevering.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Heh, what a mess! Think I've found the silver bullet. There have been some trouble with travis python 2.7 intervening with system python 2.7. To be specific, travis python have compiled pkg_resources of the system, giving me all this trouble.

@arve0
Copy link
Contributor Author

arve0 commented May 24, 2015

Btw, do we want to test for PIL (python-imaging) also? If so, I will have to find up some cleverness for hindering the pillow wheel install.

@blink1073
Copy link
Member

Yes, we explicitly support and tested against PIL. 


Sent from Mailbox

On Sun, May 24, 2015 at 5:18 PM, Arve Seljebu notifications@github.com
wrote:

Btw, do we want to test for PIL (python-imaging) also? If so, I will have to find up some cleverness for hindering the pillow wheel install.

Reply to this email directly or view it on GitHub:
#1526 (comment)

else
virtualenv -p python --system-site-packages ~/venv
virtualenv -p $(which python) ~/venv
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think the $(which python) is what is breaking your build, try reverting this line.

arve0 added 2 commits May 25, 2015 12:41
- cython is not a runtime dependency
- dask is a runtime dependency
- scikit-image depends on six.moves.urllib
- cython added to setup_requirements
  - setuptools will call easy_install to install it
  - all other build requirements, excluding numpy, will be resolved by pip
- do not parse requirements.txt
  - requirements should be the real runtime requirements
- fail gracefully when missing numpy
  - scipy will be resolved by pip from install_requires
@arve0 arve0 force-pushed the installation_instructions branch from f0fac87 to f51be32 Compare May 25, 2015 10:53
@arve0
Copy link
Contributor Author

arve0 commented May 25, 2015

I'm leaving it with this. I'm confident my changes are sound and what remains are test environment issues.

I've cleaned up the commit noise, the total should be:

Changes in skimage

  • Now requires scipy, numpy and dask[array].
    • The effect is that when scikit-image is installed from binaries (read wheel, that is OS X as of now), dependencies will be correctly installed. This is the only (consistent) way to resolve deps, as setup.py never runs when installing a wheel.
  • Removed some magic in setup.py.
  • Gracefully fail when running setup.py and missing numpy.

For the source installs, it's not the same story as with wheels, as it will run setup.py (and fail), never getting to install_requires. Though, if pip are able to run setup.py, it can resolve runtime dependencies (which are overlapping with build dependencies) and build dependencies (setup_requires, a setuptools easy_install directive). So we put build dependencies which do not overlap with runtime dependencies (cython), in setup_requires.

Changes in travis

  • Install binaries from wheel house first
    • Let pip requirements.txt sort out the rest

Changes to appveyor

  • Do not install cython 0.20
  • resolve dask[array] from /requirements.txt

arve0 added 2 commits May 25, 2015 17:04
- cython 0.20 in wheel house is below scikit-image requirement (>=0.21)
  - cython 0.21 will be installed anyhow, save time not installing
    cython twice
- dask[arrary] is added to /requirements.txt, and should not be needed
  here
requirements.txt should hold all dependencies all deps are not in wheel house

- first install binaries from wheel house
- then install the rest of the deps
@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

2.7 segfaults (numpy 1.6.0 not supported)? https://travis-ci.org/arve0/scikit-image/jobs/64372909

@blink1073
Copy link
Member

@arve0, I just built numpy 1.6.1 for the wheelhouse.

Try this fix for the intermittent 3.2 error:

diff --git a/skimage/io/tests/test_pil.py b/skimage/io/tests/test_pil.py
index cd4e893..07e558e 100644
--- a/skimage/io/tests/test_pil.py
+++ b/skimage/io/tests/test_pil.py
@@ -230,9 +230,9 @@ class TestSaveTIF:
     def roundtrip(self, dtype, x, compress):
         with temporary_file(suffix='.tif') as fname:
             if dtype == np.bool:
-                expected = ['low contrast']
+                expected = ['low contrast|unclosed file']
             else:
-                expected = []
+                expected = ['unclosed file|\A\Z']
             with expected_warnings(expected):
                 if compress > 0:
                     imsave(fname, x, compress=compress)

@blink1073
Copy link
Member

@arve0, mind if I stop the previous builds in favor of the latest?

@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

@blink1073 Go ahead. Made me think that building all PRs might not be a good idea, but I'm uncertain if its possible to build PRs "on command"?

@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

Looks like it's gonna pass now: https://travis-ci.org/arve0/scikit-image/builds/64385969

A though: A binstar organization channel might be a good fit for official windows install. What do you think?

@blink1073
Copy link
Member

@arve0, I'll let @matthew-brett weight in on binstar vs. rackspace.

@blink1073
Copy link
Member

I canceled the builds, and yes, they can be re-run at any time.

@blink1073
Copy link
Member

@arve0, what happened to your updated install instructions?

@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

@blink1073, @matthew-brett: Just to be clear and explicit, what I'm thinking of is for Windows users of scikit-image (which are not using a python distribution), not the test system.

pip install --find-links=binstar-channel scikit-image is a major improvement to

  • download goehlke packages
  • install one by one (hope there is no unresolvable deps)
  • then install scikit-image

Not sure what happened to the updated install instructions, I'll try to find them.

@arve0 arve0 force-pushed the installation_instructions branch from 51f367e to 8952154 Compare May 28, 2015 12:45
@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

Found the updated install instructions, thank god (Linus) for git. Cleaned up some commits.

@arve0
Copy link
Contributor Author

arve0 commented May 28, 2015

You may want to stop the test in favor for #1530, as the test has already passed here: https://travis-ci.org/arve0/scikit-image

@stefanv
Copy link
Member

stefanv commented May 28, 2015

@Arve The binstar command looks fine, but would look much better if we can figure out how to build our own windows packages.

This is taking forever to debug; I have a branch on which I am trying out Drone, which seems to be more responsive (at least until they reach the same level of success as Travis-CI, I presume)

@blink1073
Copy link
Member

@stefanv, I love everything about drone.io except for not having parallel builds.

@blink1073
Copy link
Member

@stefanv, we could be a bit smarter about our builds.  We could do one "extra" thing per build: docs, gallery, app gallery, optional dependecies.  


Sent from Mailbox

On Thu, May 28, 2015 at 5:15 PM, Stefan van der Walt
notifications@github.com wrote:

@Arve The binstar command looks fine, but would look much better if we can figure out how to build our own windows packages.

This is taking forever to debug; I have a branch on which I am trying out Drone, which seems to be more responsive (at least until they reach the same level of success as Travis-CI, I presume)

Reply to this email directly or view it on GitHub:
#1526 (comment)

@JDWarner
Copy link
Contributor

Thanks for sticking this out, @arve0!

I'm merging this, as it is blocking the dask[array] parallel PR and should fix the intermittent unclosed file error. Any other tweaks, improvements, etc. can happen in separate PRs.

JDWarner added a commit that referenced this pull request May 29, 2015
Add dask[array], improve CI builds, update install instructions
@JDWarner JDWarner merged commit 3faa321 into scikit-image:master May 29, 2015
@blink1073
Copy link
Member

Well done @arve0, I owe you a beverage of choice!

@arve0 arve0 deleted the installation_instructions branch May 29, 2015 16:02
@arve0
Copy link
Contributor Author

arve0 commented May 29, 2015

More likely I owe you guys a beverage of choice for keeping scikit-image up to such a high quality!

Pre-built installation
Installing scikit-image
-----------------------
If you are on Mac OS X you're lucky, open the terminal and install
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why the comment about people on OSX being lucky? I'd get rid of this.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Surely you did not forget that OSX is the world's most advanced operating system?

And that the latest MacBook is also available in gold?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because wheels exists and installation is straight forward containing only one step.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But joking aside, in this particular case, if you are on OSX, you are lucky. Not a value judgement about operating systems, just a comment on the convenience of pip installs.

Copy link
Member

@stefanv stefanv May 29, 2015 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@stefanv
Copy link
Member

stefanv commented May 29, 2015

@JDWarner This was a premature merge on the docs front.

@JDWarner
Copy link
Contributor

@stefanv I was going to address that in a separate PR as the technical work was done here, blocking other PRs, and discussions about wording can get lengthy.

Didn't see your comments until I submitted #1533 just now, but I think I've addressed most of them. If you prefer to be the PR owner, feel free to close #1533.

@stefanv
Copy link
Member

stefanv commented May 29, 2015

See #1535

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Error installing skimage-
6 participants