-
Notifications
You must be signed in to change notification settings - Fork 21
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Put on conda-forge #25
Comments
@CJ-Wright - that would be surely useful. Can you give it a start by trying to When I originally worked on conda recipies, the "boost" and "gsl" packages were either unavailable or broken in the The sequence to build the entire diffpy-cmi suite should be as follows:
Let me know if you run into a problem building any of those. |
Is there any way to contact the maintainer of |
@CJ-Wright, @sbillinge - I am in touch with James Hester and submitted a few PRs for pycifrw. He has recently asked me to check the merge of py2/py3 versions. I will do so and let him know about the conda-forge effort. I am not sure if CI and especially coverage would be straightforward. PyCifRW sources are in "noweb" format which mixes source files with documentation. The build process first extracts ".py" files from the ".nw" sources and then uses them to produce the actual package. We could suggest James to convert the library to standard ".py" sources with rst documentation, I am however not sure if we have time and resources to help him doing so. |
At the very least we can build and test on a CI right? |
The main repo is on bitbucket (https://bitbucket.org/jamesrhester/pycifrw), which travis does not seem to support #667. Perhaps there are other alternatives that work there - would you mind to check what are the CI options for bitbucket? Another possibility is to mirror - with permission - on GitHub and setup the CI testing there. |
If we are in touch with James Hester, then it is probably less work to seek permission to mirror on GitHub? |
Perhaps we should refocus to the initial question - @CJ-Wright - did you have a chance to test out a full build sequence of conda packages for diffpy-cmi? I wonder if we can switch to the standard/conda-forge versions of the boost and gsl packages or if we need to continue building our own. The gsl and boost are required for libdiffpy, pyobjcryst and srreal, so these builds will show if standard versions work. |
I don't know exactly what you mean, but using the source install we could change over the deps to conda-forge. I can't start building |
I meant to build all conda packages for CMI locally, install them with the |
@CJ-Wright - any new progress with testing package build sequence locally w/r to conda-forge? |
Sorry for the delay, I don't have a ton of time but I can try to get all the PRs in today. I usually test all the builds locally individually before sending them up to conda-forge. The tests will fail if there is a problem with the C++ libraries, right? |
@CJ-Wright - Right - the idea is to test if a full package stack would work with gsl and boost dependencies from conda-forge. Perhaps it is better to reassign to someone else in the group and get more people experienced with building conda packages. @dragonyanglong, @gzz0707, @justcalamari, @chiahaoliu - any volunteer to test a build of diffpy-cmi package stack w/r to conda-forge libraries? |
I noticed the toolchain package for configuring conda-forge builds bumped up minimum Mac OS X version to 10.9 conda-forge/toolchain-feedstock@7a470c5. The stock conda-build uses 10.7. Does anyone have access to a Mac with earlier OS, e.g., Mountain Lion 10.8? conda create --name=cf27 --channel=conda-forge python=2.7
source activate cf27
# does this run or crash?
python |
If anyone else is interested in doing the packaging, they are more than welcome to it. I have posted all the package PRs in this issue, and mark off the ones that are accepted/exist. |
@CJ-Wright - I feel we should do a complete test of diffpy-cmi stack locally first and then decide if it is worth adding recipes to conda-forge. @sbillinge - chances are conda-forge packages do not work on slightly older Mac-s which are still supported by stock Anaconda. Do we want to cut those users out by moving our packages to conda-forge or should we continue building packages on our own that work for them? Also - distributing our packages from the diffpy channel makes it easier to see their download statistics. This would get more tricky if they are available at 2 channels (conda-forge and diffpy). |
Would it be possible to put all of this on conda-forge?
The text was updated successfully, but these errors were encountered: