Closed ax3l closed 8 years ago
Right - with anaconda you don't need any sudo privileges.
Once the plugin is complete and we have an updated frozen binary, that can be run from anywhere.
@giumas :) oh dang, why do I always forget about conda in my pip-centric world... touché!
@jreadey that sounds excellent, so users do not need to tackle the whole install process. maybe providing a pip and/or a conda package would also be a good channel for shipping.
Besides that: should we add a small section to the Readme.rst about the required steps to install the dependencies? Idea if you prefer conda over pip:
Required dependencies:
conda install:
conda install numpy matplotlib wxPython
Optional dependencies:
conda install:
conda install h5py
conda install -c https://conda.anaconda.org/giumas hydroffice.bag
conda install -c https://conda.anaconda.org/nsidc pydap
conda install requests
For packaging the app:
For packaging the app:
@ax3l Actually, an experimental wheel that I did is already on PyPi: https://pypi.python.org/pypi/hdf_compass (as well as for hydroffice.bag
: https://pypi.python.org/pypi/hydroffice.bag/0.2.6)
However, from my understanding (@jreadey, please corrects me if I am wrong) the current approach of the HDF Group is to focus more on providing a frozen application than supporting pip
/conda
packages.
About dependencies: I am not sure that the intent is to prefer conda
over pip
. We usually adopt the easiest combination per-platform to get at the point of having a working environment for freezing.
@giumas - right, I think as an application targeted for the non-python users, the frozen binary approach is best (at least for Windows and OS X). I've been putting binaries out on S3 (see https://github.com/HDFGroup/hdf-compass/issues/79).
I'm not opposed to building Compass based on binaries from pip rather than Anaconda, but my earlier attempts weren't too successful. Packages based on Python + non-python bits can be tricky to set up (re: my failure to get the cartopy feature working). For new dependencies having step by step build instructions for a clean system would be best.
Also please don't forget to provide a solid source release for us, Linux packagers :-)
FYI, I successfully managed to create a Debian package based on the latest snapshot from master
, but we prefer distributing packages for official
releases, beit alpha, beta, rc or stable quality. So please consider tagging or releasing other development tarballs if you are interested. Meanwhile, I will be happy to forward any feedback regarding the easiness of building the application from source to you guys.
Cheers,
@jreadey Many improvements have been added in development
. Should we reconsider https://github.com/HDFGroup/hdf-compass/issues/79 ? We could move some of the missing tasks to 0.7.0
(or whatever you think is more appropriate) making a rc
with the current snapshot.
@giumas - agreed. I've been busy with other project commitments in Jan, but I'll try to create frozen binaries next week for Windows and OS X. I'll review the feature list of #79 with the aim of getting a "official" release out in Feb.
@ghisvali - a Debian package for Compass sounds great. I've tried putting out frozen binaries for Linux CentOS but as a rule they don't work on other Linux distros. For Linux packaging can binaries be built from Python source snapshots? I'd think dealing with the Python package dependencies would be a bit of a challenge.
For Linux packaging can binaries be built from Python source snapshots?
As a general rule, Linux binary packages are always built from a source release. As long as the project can be installed via a regular call to python setup.py install
, it is package-able. I am not sure what you mean by "snapshots" here, but generally speaking we sync the packaging with new releases on PyPI or new release tags on GitHub.
dealing with the Python package dependencies would be a bit of a challenge.
There are mechanisms in place to parse the setup metadata in order to generate the list of install dependencies automatically. Often the challenge for us is to have the build or mandatory install dependencies packaged first. I believe here we have everything in place on Debian besides hydroffice.bag
, which is optional anyway.
Let me re-confirm that I already managed to create a Debian package locally from an unreleased snapshot off master
and the application seems to run properly. I was able to explore a simple test HDF5 dataset locally on my machine.
@ghisvail Since I am the packager of hydroffice.bag
, I would like to make it available on Debian. The project (pure Python) is hosted on bitbucket with a mirror on github.
By reading this document, it looks like the current Python wheel is not the best solution. Do you have suggestions on what would be the best approach? Tagging the mirror? Loading a tarball in PyPi?
@ghisvail Is this enough? https://github.com/giumas/hyo_bag/releases/tag/v0.2.6
Tagging the mirror? Loading a tarball in PyPi?
Any or both.
Is this enough? https://github.com/giumas/hyo_bag/releases/tag/v0.2.6
Perfect.
FYI, I'll be happy to package hydroffice.bag
(as an optional install dependency to hdf-compass) but my main motivation remains to make hdf-compass
available to the Debian science community, as part of the HDF5 stack that I already maintain. Please consider evaluating whether a release can be tagged soon, so I can submit an official package to the archive. Feel free to ping me when such release is available. Thanks.
I believe that this ticket has been more or less solved.. and there is a dedicated ticket for debian: https://github.com/HDFGroup/hdf-compass/issues/160
Just a remark on one of the major dependencies of this project: wxPython Phoenix.
As a Linux user, if you are not root on your machine this is pretty hard (let's say rather impossible) to install. The main problem is the requirement of a development version of gstreamer (side note: a pretty old version of gstreamer).
Is there any way to circumvent that dependency as a developer besides hoping to be/know root?
Edit: After half a day we finally found a way to disable a specific control that triggers that dependency by building from source and disabling the
mediactrl
inbuild/tools/build-wxwidgets.py
by hand (--enable-mediactrl
->--disable-medaictrl
). Could not find a useable command flag to do so insetup.py
(/pip).