You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a proposal for how we can manage Pandana packaging going forward. Goals: easy installation, broad compatibility, simpler release process, limited maintenance.
Background
Pandana includes C++ code, so binary distributions need to be compiled for each combination of operating system and Python version it will run on. This is a lot of work and we've never done a good job covering every combination.
I'm proposing that we focus on (a) installation from source and (b) installation from Conda Forge, and not create any binary distributions ourselves.
Installing from source
We should aim to make this as automatic as possible.
Source installation works using compilation settings from setup.py. Running pip install . or python setup.py install (or develop) will attempt to compile the C++ extension accordingly.
This has often been broken, but it's working now (after the latest round of updates for v0.4.2) on all platforms. We'll need to keep setup.py up to date, though.
Requirements for compilation:
Mac: Xcode command line tools (usually already installed, e.g. for Git)
Linux: none, generally
Windows: Visual C++ 9.0 (for Python 2.7) or 14.0 (for Python 3.5 to 3.7)
On Mac, compilation with multi-threading support requires some extra steps: #109 (comment)
Installing from Conda
This should be the go-to option for users.
Conda Forge automatically compiles binaries for all platforms, using setup.py plus some additional settings in the Conda build recipe. I haven't set it up yet, but it looks pretty straightforward, including multi-threading support for Mac.
Previously we've distributed Pandana on the udst Conda channel, but we're aiming to migrate to conda-forge anyway.
Installing from Pip
This should be somewhat discouraged.
I don't see any way to create binary distributions for Pip without maintaining half a dozen cross-platform VMs. I'm proposing we skip that and only put the source distribution on Pip.
This will generally install fine on Mac and Linux; it will automatically compile on the user's machine, in about 15 seconds. It will not have multi-threading support on Mac.
It probably won't work for most Windows users, but Sam Blanchard reports that some of the other geospatial dependencies don't install well from Pip anyway, and it's best to use Conda on Windows.
The text was updated successfully, but these errors were encountered:
@sablanchard @federicofernandez @janowicz
This is a proposal for how we can manage Pandana packaging going forward. Goals: easy installation, broad compatibility, simpler release process, limited maintenance.
Background
Pandana includes C++ code, so binary distributions need to be compiled for each combination of operating system and Python version it will run on. This is a lot of work and we've never done a good job covering every combination.
I'm proposing that we focus on (a) installation from source and (b) installation from Conda Forge, and not create any binary distributions ourselves.
Installing from source
We should aim to make this as automatic as possible.
Source installation works using compilation settings from
setup.py
. Runningpip install .
orpython setup.py install
(ordevelop
) will attempt to compile the C++ extension accordingly.This has often been broken, but it's working now (after the latest round of updates for v0.4.2) on all platforms. We'll need to keep
setup.py
up to date, though.Requirements for compilation:
On Mac, compilation with multi-threading support requires some extra steps: #109 (comment)
Installing from Conda
This should be the go-to option for users.
Conda Forge automatically compiles binaries for all platforms, using
setup.py
plus some additional settings in the Conda build recipe. I haven't set it up yet, but it looks pretty straightforward, including multi-threading support for Mac.Previously we've distributed Pandana on the
udst
Conda channel, but we're aiming to migrate toconda-forge
anyway.Installing from Pip
This should be somewhat discouraged.
I don't see any way to create binary distributions for Pip without maintaining half a dozen cross-platform VMs. I'm proposing we skip that and only put the source distribution on Pip.
This will generally install fine on Mac and Linux; it will automatically compile on the user's machine, in about 15 seconds. It will not have multi-threading support on Mac.
It probably won't work for most Windows users, but Sam Blanchard reports that some of the other geospatial dependencies don't install well from Pip anyway, and it's best to use Conda on Windows.
The text was updated successfully, but these errors were encountered: