option to not use bundled libraries

[jdkloe]

the new bundling policy of Fedora requires to ask upstream, to provide the option to not use the bundled libraries, but use system libraries in stead.
For basemap, currently geos already has this option, but also pyproj and pyshp are bundled. These last two do not have the option to use the system version of the library. Are there fundamental reasons why this is not provided?
If not would you be willing to merge a pull request from my side that implements this?

[WeatherGod]

I can only surmise that the reason for bundling pyshp and pyproj has to do
with historical issues with dependency handling. I would be more than happy
to accept a PR that makes this optional.

On Thu, Nov 26, 2015 at 3:30 PM, Jos de Kloe notifications@github.com
wrote:

the new bundling policy of Fedora requires to ask upstream, to provide the
option to not use the bundled libraries, but use system libraries in stead.
For basemap, currently geos already has this option, but also pyproj and
pyshp are bundled. These last two do not have the option to use the system
version of the library. Are there fundamental reasons why this is not
provided?
If not would you be willing to merge a pull request from my side that
implements this?

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

[micahcochran]

I'm working on making pyproj and pyshp external dependencies.

In my opinion, it would make development cleaner because those libraries have entirely separate github development sites. Reporting of issues with those code bases could be referred to those projects. Many users will probably install the most recent version of the dependent packages. Some may already have those packages installed.

[WeatherGod]

Agreed. Let's aim to not bundle at all.

On Mon, Nov 30, 2015 at 4:25 PM, Micah Cochran notifications@github.com
wrote:

I'm working on making pyproj and pyshp external dependencies.

In my opinion, it would make development cleaner because those libraries
have entirely separate github development sites. Reporting of issues with
those code bases could be referred to those projects. Many users will
probably install the most recent version of the dependent packages. Some
may already have those packages installed.

—
Reply to this email directly or view it on GitHub
#230 (comment).

[micahcochran]

Here is what I've gotten so far.

I still need to update setup.py. distutils doesn't seem to understand install_requires, which is where dependencies are listed. While running this setup.py I got this message:

/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'install_requires'

I will need to investigate if setuptools is the only way to do this and how numpy.distutils stack up.

[WeatherGod]

setuptools introduced the "install_requires" feature, not distutils. This
stuff will need to be ported over to use setuptools if we want automatic
dependency resolution.

On Mon, Nov 30, 2015 at 5:41 PM, Micah Cochran notifications@github.com
wrote:

Here is what I've gotten so far.
https://github.com/micahcochran/basemap/tree/ext-pyshp-pyproj

I still need to update setup.py. distutils doesn't seem to understand
install_requires, which is where dependencies are listed. While running
this setup.py I got this:

/usr/lib/python3.4/distutils/dist.py:260: UserWarning: Unknown distribution option: 'install_requires'

I will need to investigate if setuptools is the only way to do this and
how numpy.distutils stack up.

—
Reply to this email directly or view it on GitHub
#230 (comment).

[jdkloe]

So the question is if basemap should move to using setuptools instead of the simpler distutils. Are there any downsides to this?

[WeatherGod]

@mdboom, do you have any thoughts on whether or not basemap should
transition to setuptools? The goals are to eliminate bundling. I wonder if
doing so would also possibly solve the whole namespace package issue.
Perhaps we might even consider transitioning away from namespace packaging
altogether?

On Tue, Dec 1, 2015 at 4:30 AM, Jos de Kloe notifications@github.com
wrote:

So the question is if basemap should move to using setuptools instead of
the simpler distutils. Are there any downsides to this?

—
Reply to this email directly or view it on GitHub
#230 (comment).

[micahcochran]

@jdkloe Setuptools is compatible down to Python 2.4. The current version for pyshp requires setuptools. The development version of pyproj requires setuptools. matplotlib appears to prefers setuptools, but will fallback to distutils. numpy is using setuptools for some cases, but also falls back to distutils. Just by having pyshp as an external dependency, the user will have to install setuptools.

Python 2.7.9 and later bundle setuptools by default, so before that version setuptools has to be installed by the user. It will add an additional installation step for some systems.

[micahcochran]

When using pip to uninstall a distutils installed project, this message is reported.

~/prj/basemap$ sudo -H pip3 uninstall basemap
DEPRECATION: Uninstalling a distutils installed project (basemap) 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.

I might be doing something wrong with the way I'm uninstalling/removing basemap.

[jenshnielsen]

If you want to reliably uninstall uninstall anything with pip you should use pip to install it too. Installing from source with pip install . rather than python setup.py install

That being said we should get rid of the namespace package which will make uninstalling and upgrading much more reliable.

@WeatherGod I have been thinking about getting rid of the mpl_toolkits namespace package for some time. My idea was something like. Move basemap to it's own package but install a shim into mpl_toolkits provided that matplotlib is less than 2.1 (or something like that) For 2.1 and upwards maplotlib would provide the shim and changing mpl_toolkits into a regular package.

[micahcochran]

@jdkloe It took me about a week, but PR #234 now works.

@jenshnielsen Thanks for the pip tip.

[jswhit]

our bundled proj.4 src contains a patch that includes the inverse hammer transform. I've submitted a pull request for this at the proj.4 github site (OSGeo/PROJ#329). Unless they merge this, making the proj.4 C lib an external dependency will break the hammer projection in Basemap.

pyproj contains it own patched version of proj.4 for this reason, but can be built using an external proj.4 lib installation.

[micahcochran]

@jswhit Thanks for submitting the pull request to proj.4 for the inverse hammer transform.

[micahcochran]

@jdkloe does the current development version satisfy the Fedora bundling policy? pyproj's inverse hammer transformation was mreged into the current development version of proj4 (4.9.3), so it is also able to be installed without a separate library.