librascal
librascal copied to clipboard
lab-cosmo
Package name `rascal` is already taken on PyPI :(
https://pypi.org/project/rascal/ has the same Python package name as ours (both do import rascal) - so basically, we need to rename our rascal python package to avoid any potential future conflict with this existing spectroscopy library. I would be fine with librascal, lrascal, or even lilrascal (as suggested by @rosecers ).
lrascal is not easy to pronounce, but I'll be fine with the other two.
Although we have been using librascal in the group to refer to this code, it feels a bit strange as a Python module name (from librascal import SphericalInvariants). Another alternative is lascar, almost reversed =)
I'd go for librascal - it's a C++ library with python bindings and it's quite common to call c++ libraries libsomething.
On Mon, 14 Jun 2021 at 14:46, Guillaume Fraux @.***> wrote:
lrascal is not easy to pronounce, but I'll be fine with the other two.
Although we have been using librascal in the group to refer to this code, it feels a bit strange as a Python module name (from librascal import SphericalInvariants). Another alternative is lascar, almost reversed =)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cosmo-epfl/librascal/issues/362#issuecomment-860655321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIREZ3SVRK4GTVSVZMGBXDTSX2ZXANCNFSM46VFDIUQ .
Another alternative is
lascar, almost reversed =)
https://pypi.org/project/verlanize/ ? Might be an option for coming up with new package names in the future, provided we start with something that's close to a pronounceable French word
I think this would be most intuitive— librascal, that is
On Jun 14, 2021, at 3:22 PM, Michele Ceriotti @.***> wrote:
I'd go for librascal - it's a C++ library with python bindings and it's quite common to call c++ libraries libsomething.
On Mon, 14 Jun 2021 at 14:46, Guillaume Fraux @.***> wrote:
lrascal is not easy to pronounce, but I'll be fine with the other two.
Although we have been using librascal in the group to refer to this code, it feels a bit strange as a Python module name (from librascal import SphericalInvariants). Another alternative is lascar, almost reversed =)
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/cosmo-epfl/librascal/issues/362#issuecomment-860655321, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIREZ3SVRK4GTVSVZMGBXDTSX2ZXANCNFSM46VFDIUQ .
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/cosmo-epfl/librascal/issues/362#issuecomment-860680387, or unsubscribe https://github.com/notifications/unsubscribe-auth/ALKVP3SFQ62P6UO47HOSPMLTSX7ANANCNFSM46VFDIUQ.
I also think we should change the python module name to match the name on pypi, i.e. from librascal import XXX instead of from rascal import XXX. While this is not mandatory, it would remove some confusion on the user side who see some script starting with import rascal, then do pip install rascal and the code still fails.
This would be a breaking change for all current users, but should be relatively easy to fix.
We have an external user who has been struggling for two days because of this. I'd say we need to act. I suggest s/rasca/librascal and put it on pipy ASAP. we've already being referring to the package as librascal, so it's the most painless renaming we can do at this stage. I can see both pros and cons in renaming the package itself, as opposed to using "librascal" on pipy. given the existence of an unrelated package, I think that a full renaming is better. "lascar" [library for atomic scale representations] is also pretty good but a more substantial change of branding...
Hello, before adding librascal to pypi, it makes sense to me that we have a stable model json format. The PRs #305 and #376 add significant changes to it. So I suggest to get these two merged before making a release.
EDIT: also PR #353
After a conversation with @max-veit I realized that the only thing, which will not be backwards compatible due to #376, are cpp representations. I don't think any python user tries to make a cpp representation directly, circumventing the python representation classes. The remaining changes in #305 only add supplementary information to the fitting file.
So I think we can actually make a release.
Excellent. Can you do that? I'll then update all branches and side-projects: will be a couple of weeks of pain, but I think it's for the greater good.
Before making a release, I think we should re-license to LGPL-v2 or later (https://github.com/cosmo-epfl/librascal/issues/303). I can take care of this if everyone is fine with it.
Jolly good.
On Thu, 9 Dec 2021 at 10:29, Guillaume Fraux @.***> wrote:
Before making a release, I think we should re-license to LGPL-v2 or later ( #303 https://github.com/cosmo-epfl/librascal/issues/303). I can take care of this if everyone is fine with it.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/cosmo-epfl/librascal/issues/362#issuecomment-989667951, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAIREZ3GVFR4WDXEW2ZHA2DUQBZGDANCNFSM46VFDIUQ .