search

openmrslab / suspect

MRS processing tools
https://suspect.readthedocs.io/en/latest/
MIT License
33 stars 23 forks source link

Conda-forge package #119

Open danilomendesdias opened 5 years ago

danilomendesdias commented 5 years ago

Hello, everyone.

Thank you very much for this project. I really enjoyed the way you modeled the MRS signals and also the I/O implementations for several software/scanners formats.

As a small contribution, I'm creating a conda package at conda-forge for suspect: https://github.com/conda-forge/staged-recipes/pull/7226

There are several advantages on using conda-forge channel for scientific purposes (faster, reliable, easy installation), you can know more here: https://conda-forge.org/

This is currently waiting for approval, but it will be available soon, so users can install it with conda install -c conda-forge suspect.

If you are interested on being maintainers of this package, please, let me know so I can include you guys on the recipe.

Cheers, Danilo

bennyrowland commented 5 years ago

Thanks, Danilo, I am glad to hear that you are finding it useful. It is good to provide different ways of installing the package, but perhaps you could expand on why you think installing with conda is easier/better than with pip, just because I am interested to learn?

Also if you think there is anything missing from Suspect for your work, please let me know as we are continuously working to improve the code. Or feel free to submit extra algorithms etc.

danilomendesdias commented 5 years ago

I really like this post of Jake Vanderplas about this: https://jakevdp.github.io/blog/2016/08/25/conda-myths-and-misconceptions. I recommend the lecture.

I'm currently working with C++ bindings for Python and using conda environments with packages from conda-forge make the workflow very handy, as conda also manages non-pythonic stuff (compilers, C++ libraries and so on). The process of package creation on conda-forge passes through a CI that automatically lints your recipe and builds your package on a lot of versions of python and operational systems. People from the organization review your work before merging. So, there is a quality control of packages that are published on conda-forge. This basically does not exists on PIP. You can publish a broken package if you try. I also like the fact that numpy/scipy from conda-forge comes with Intel MKL. Actually, these huge libraries are maintained by a lot of people that are concerned with performance, portability and so on. Thus, resulting binaries tend to be very good.

You can also use PIP inside conda environments, although this is not recommended.

PIP is very nice for its main purpose: make python packages be published. Wheels seems to solve some boring stuff of compiling Numpy/Scipy, but I think it is not even close from what conda-forge already achieved in this sense. Even conda-forge downloads the source from PyPi in order to create the packages. But if you want to take advantage of optimized scientific binaries and have multiple environments to test different versions of python, libraries and etc, conda + conda-forge can help you with that. I remember to have a lot of issues when trying to install packages with PIP and most of these problems are just gone. Nothing is perfect, but I think that people from conda/conda-forge are dedicating more time with our kind of work while people from PyPi/PIP have more general issues to be worried about.