ioos / conda-recipes

conda-recipes for IOOS packages
20 stars 29 forks source link

Proj4 on win64 issues #413

Closed rsignell-usgs closed 9 years ago

rsignell-usgs commented 9 years ago

I'm having trouble creating new environments with proj4 that work on win64.

This environment doesn't work:

[ioos] C:\programs\anaconda-64>conda list proj
# packages in environment at c:\programs\anaconda-64\envs\ioos:
#
proj.4                    4.9.1                         0    defaults
proj4                     4.9.1                    py27_4    ioos
pyproj                    1.9.4                    py27_1    defaults

In another environment, I uninstalled pyproj and proj4, then forced the install of proj4 from the ioos channel, and then tried to install pyproj from the ioos channel, but I couldn't get the ioos channel version because it has the identical version and build number as the default channel:

[pygdp] C:\programs\anaconda-64>conda list proj
# packages in environment at c:\programs\anaconda-64\envs\pygdp:
#
proj4                     4.9.1                    py27_4    ioos

[pygdp] C:\programs\anaconda-64>conda install pyproj
Fetching package metadata: ........
Solving package specifications: .
Package plan for installation in environment c:\programs\anaconda-64\envs\pygdp:

The following NEW packages will be INSTALLED:

    proj.4: 4.9.1-0      defaults
    pyproj: 1.9.4-py27_1 defaults

Proceed ([y]/n)? n

I then thought I could just bump the build number on the pyproj recipe, but found that it has been deprecated from the ioos channel.

Luckily I still have one environment (I can't remember when I created it) that still works, with both proj4 and pyproj from the ioos channel:

[flopy] c:\Users\rsignell\Documents\GitHub>conda list proj
# packages in environment at c:\programs\anaconda-64\envs\flopy:
#
proj4                     4.9.1                    py27_4    ioos
pyproj                    1.9.4                np19py27_1    https://conda.binstar.org/ioos/win-64/pyproj-1.9.4-np19py27_1.tar.bz2

I'm supposed to help python windows users install working conda environments in a few hours, but I have no idea how to recreate my working environment! :sob:

ocefpaf commented 9 years ago

Did you try uninstalling ioos proj4 and use all from de default channel? I had hope to deprecate proj too.

I'm having trouble creating new environments with proj4 that work on win64.

This environment doesn't work:

[ioos] C:\programs\anaconda-64>conda list proj

packages in environment at c:\programs\anaconda-64\envs\ioos:

# proj.4 4.9.1 0 defaults proj4 4.9.1 py27_4 ioos pyproj 1.9.4 py27_1 defaults

In another environment, I uninstalled pyproj and proj4, then forced the install of proj4 from the ioos channel, and then tried to install pyproj from the ioos channel, but I couldn't get the ioos channel version because it has the identical version and build number as the default channel:

[pygdp] C:\programs\anaconda-64>conda list proj

packages in environment at c:\programs\anaconda-64\envs\pygdp:

# proj4 4.9.1 py27_4 ioos

[pygdp] C:\programs\anaconda-64>conda install pyproj Fetching package metadata: ........ Solving package specifications: . Package plan for installation in environment c:\programs\anaconda-64\envs\pygdp:

The following NEW packages will be INSTALLED:

proj.4: 4.9.1-0      defaults
pyproj: 1.9.4-py27_1 defaults

Proceed ([y]/n)? n

I then thought I could just bump the build number on the pyproj recipe, but found that it has been deprecated from the ioos channel.

Luckily I still have one environment (I can't remember when I created it) that still works, with both proj4 and pyproj from the ioos channel:

[flopy] c:\Users\rsignell\Documents\GitHub>conda list proj

packages in environment at c:\programs\anaconda-64\envs\flopy:

# proj4 4.9.1 py27_4 ioos pyproj 1.9.4 np19py27_1 https://conda.binstar.org/ioos/win-64/pyproj-1.9.4-np19py27_1.tar.bz2

I'm supposed to help python windows users install working conda environments in a few hours. [image: :sob:]

— Reply to this email directly or view it on GitHub https://github.com/ioos/conda-recipes/issues/413.

rsignell-usgs commented 9 years ago

@ocefpaf , yes, I tried that. If I use the defaults only I get errors like this:

---------------------------------------------------------------------------
ValueError                                Traceback (most recent call last)
<ipython-input-4-9e78167f64a6> in <module>()
      1 # Load MODFLOW output files
      2 from modflow2netcdf.output import ModflowOutput
----> 3 mf = ModflowOutput('freyberg.nam', config_file=freyberg_config, exe_name="mf2005", model_ws=freyberg_ws, verbose=True)

c:\programs\anaconda-64\envs\pygdp\lib\site-packages\modflow2netcdf\output.pyc in __init__(self, namfilename, config_file, version, exe_name, verbose, model_ws)
     65         # Now process
     66         with LoggingTimer("Parsing config file", logger.info):
---> 67             self.parse_config_file(config_file)
     68         self.get_coordinates()
     69 

c:\programs\anaconda-64\envs\pygdp\lib\site-packages\modflow2netcdf\output.pyc in parse_config_file(self, config_file)
    540                 self.grid_crs = Proj(init='epsg:{0!s}'.format(self.config_crs))
    541             except RuntimeError:
--> 542                 raise ValueError("Could not understand EPSG code '{!s}' from config file.".format(self.config_crs))
    543 
    544             # Units

ValueError: Could not understand EPSG code '4269' from config file.
ocefpaf commented 9 years ago

I re-added our version pyproj (#415) which uses the bundled c-code and not the installed proj4. That is not an elegant solution but should fix this issue. Let me know if that works for you.

ocefpaf commented 9 years ago

I just tested the following code snippet,

from pyproj import Proj
Proj(init='epsg:4269')

and it worked on a Win32 VM and #415.

rsignell-usgs commented 9 years ago

@ocefpaf to the rescue! It works! Just in the nick of time! The training starts in 20 mins! THANK YOU!!!!

ocefpaf commented 9 years ago

Phew. I introduced this bug :flushed: so I had to fix it.

Conda still has some rough edges. For example we cannot:

1) Rely on the default channel packages. (See a similar issue with Shapely here.)

2) Add a preference order for the channels. That will ensure we will get the desired package even if the channels have the same version. (I opened a feature request for this in conda a long time ago :unamused: )

rsignell-usgs commented 9 years ago

This totally saves our butts yesterday in the class. It worked fine for everyone!

ocefpaf commented 9 years ago

It is worth creating a SSCCE with using the default channel and reporting to continuum.