Skip to content
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

release for conda #3

Closed
martindurant opened this issue Mar 9, 2020 · 8 comments
Closed

release for conda #3

martindurant opened this issue Mar 9, 2020 · 8 comments

Comments

@martindurant
Copy link

This seems like a very useful package, if it is small, fast and compliant!
I'm sure users would appreciate installing pre-compiled versions from conda.
https://conda-forge.org/docs/maintainer/adding_pkgs.html

@martindurant
Copy link
Author

ping here - I believe this step would help adoption

@milesgranger
Copy link
Owner

milesgranger commented Jul 16, 2020

I've made a feeble attempt. I don't use Conda, and as the packages are already pre-compiled as .whl files on PyPi I wasn't sure how to again pre-compile them via a Conda Recipe, so thought it was possible to just use the existing wheels with --no-deps. Maybe you could give me a small pointer? Thanks!

conda-forge/staged-recipes#12159

I suspect it's b/c I'm not putting in the absolute URL to the file, but using this as a reference I wasn't sure how to parameterized it by python version and OS in the build scripts... 😕

@martindurant
Copy link
Author

If you continue to pole the conda-forge maintainers, they will eventually show the "right" way to do things!
By the way, do you have any benchmarking for the various algorithms?

@milesgranger
Copy link
Owner

I did some a while ago, if I remember correctly the snappy variant was a touch slower than python-snappy but gzip was nearly twice as fast as the the std lib Python. I didn't compare the other variants to other Python implementations, however, it's probably a good thing to create some basic comparisons at least. 👍

@milesgranger
Copy link
Owner

milesgranger commented Jul 18, 2020

Thanks for the help, even though we still can't get it to use the wheels on PyPi it seems.

Maybe I'm being dense, but I'm struggling to understand why having the package available on conda-forge is advantageous to the defacto standard pypi, namely because the package is already pre-compiled on pypi. This bit of documentation seems to suggest that conda's environment.yml file can handle pip dependencies as well.

Additionally, it seems with each new release, for example v1.3.0, I would need to fork and update the recipe; whereas with pypi, it's automated after simply creating the tag on Github.

Don't get me wrong, I'm still open for trying to get it on conda-forge, it's just that I don't fully understand the benefit to it yet, and that it will cause me more work for releases. 🤔

@milesgranger
Copy link
Owner

Hi @martindurant

For the second point about benchmarking, I added an update with better benchmarking in #12 so you can see those now here in the benchmarks more-or-less on par with python-snappy. Let me know if you have any suggestions! 😄

@martindurant
Copy link
Author

Thanks!
Someone very motivated might try to find the reasons for the differences.
Isn't zstd missing, or is that not implemented?

@milesgranger
Copy link
Owner

ah indeed, I must have glossed over it. Benchmarks have been updated, thanks! 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants