wblumberg
commented
4 years ago Hi @djhoese . Thank you for your contribution. I have considered this for a long time, and your post got this going. I think I was overcomplicating that process...now that I've spent some time going through it I think I may end up ditching the "SHARPpy" channel on Anaconda Cloud. Here's the current conda-forge pull request:
https://github.com/conda-forge/staged-recipes/pull/10933
Latest results show that the CI that handles generating these packages can build on Python 3.6 and 3.7 for Linux, macOS, and Windows. Upon install of the SHARPpy package through conda-forge, there should be two tests: 1) an import test and 2) a test to make sure the CLI works.
Some notes for future Greg:
- The initial recipe pushed is for the v1.4.0b1 version of SHARPpy (not v1.3.0).
- OpenGL.so.1 has issues on Linux, so I couldn't build using a noarch flag. This was resolved using this link: https://conda-forge.org/docs/maintainer/knowledge_base.html#libgl
- There was some weird bug with python-dateutil conflicting with the linter. Got around this by adding a version constraint to this package (>=2). This should handle this issue pretty well.
- Somewhere I might be able to attach a DOI to the SHARPpy paper in the meta.yaml.
djhoese
I don't personally use SHARPpy but have a lot of colleagues that use it or want to use it. I'm wondering what the maintainers' thoughts are on producing a package on conda-forge? Is there anything stopping this from being possible? SHARPpy is/can be distributed as a python package, right?