numpy version clash when installing blocks

[gnperdue]

Hello,

I tried to install blocks on top of an anaconda distribution and ran into trouble. I am using Mac OSX Yosemite.

1. I installed a fresh anaconda distribution: bash Anaconda2-2.5.0-MacOSX-x86_64.sh
2. I installed blocks: pip install git+git://github.com/mila-udem/blocks.git@stable -r https://raw.githubusercontent.com/mila-udem/blocks/stable/requirements.txt

The installer requires numpy 1.9.3 and anaconda currently ships with 1.10.4. So the installer attempted to remove 1.10.4:

  Found existing installation: numpy 1.10.4
    DEPRECATION: Uninstalling a distutils installed project (numpy) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
    Uninstalling numpy-1.10.4:
      Successfully uninstalled numpy-1.10.4

It then installed 1.9.3 and this broke a variety of things. In particular, I could not import theano without errors about the numpy version (which I don't seem to have saved).

I was able to fix this by forking blocks and changing the requirements file to use numpy 1.10.4. If I then repeated my two step installation procedure above (this time pointing to my blocks), everything worked.

I can submit a pull request with the updated numpy version, but I don't know if this breaks some other subtle thing. Either way I wanted to point this out in case someone else came across it.

Thanks!

[dwf]

@bartvm shouldn't that be >=1.9.3? Bit harsh to require exactly numpy
1.9.3... I never install with pip so I don't know.

On Tue, Feb 16, 2016 at 3:47 PM, Gabriel Perdue notifications@github.com
wrote:

Hello,

I tried to install blocks on top of an anaconda distribution and ran into
trouble. I am using Mac OSX Yosemite.

1. I installed a fresh anaconda distribution: bash
   Anaconda2-2.5.0-MacOSX-x86_64.sh
2. I installed blocks: pip install git+git://
   github.com/mila-udem/blocks.git@stable -r
   https://raw.githubusercontent.com/mila-udem/blocks/stable/requirements.txt

The installer requires numpy 1.9.3 and anaconda currently ships with
1.10.4. So the installer attempted to remove 1.10.4:

Found existing installation: numpy 1.10.4
DEPRECATION: Uninstalling a distutils installed project (numpy) has been deprecated and will be removed in a future version. This is due to the fact that uninstalling a distutils project will only partially uninstall the project.
Uninstalling numpy-1.10.4:
Successfully uninstalled numpy-1.10.4

It then installed 1.9.3 and this broke a variety of things. In particular,
I could not import theano without errors about the numpy version (which I
don't seem to have saved).

I was able to fix this by forking blocks and changing the requirements
file to use numpy 1.10.4. If I then repeated my two step installation
procedure above (this time pointing to my blocks), everything worked.

I can submit a pull request with the updated numpy version, but I don't
know if this breaks some other subtle thing. Either way I wanted to point
this out in case someone else came across it.

Thanks!

—
Reply to this email directly or view it on GitHub
#990.

[bartvm]

It's intentionally pinned to exactly 1.9.3. We've had problems where a new package version broke things (think Bokeh). If we don't pin it, Travis breaks out of nowhere and people start filing bug reports, leaving us scrambling to fix things. With things pinned, technically speaking, user installations should always work because they have the exact same set of packages we test against.

Requires.io is supposed to make pull requests to requirements.txt to make sure it stays up to date (see #977) but it looks like it's a bit behind.

In short, we just need to update all the requirements files to be up to date with the newest ones available in Conda.

[dwf]

Working as intended, then? I guess we can tell people to install with --no-deps and manually get newer dependencies if they want them but that they are rolling the dice.

Ideally I think we should pin packages we have problems with like bokeh, but mature packages with sane deprecation policies (e.g. NumPy and SciPy) we could pin at a minimal version instead.