-
Notifications
You must be signed in to change notification settings - Fork 14
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
Pulling out super small modules? #1208
Comments
An alternative would be to create one package for commonly used utilities like the https://github.com/materialsvirtuallab/monty package from the materials project. |
Yes, that might be really nice. It might be nice to collect all the tools and tidbits that, eg, depend exclusively on the standard library. Then they could be added to literally any project with almost zero overhead. |
As of the meeting today we decided that this is a fine idea. Any bits of pieces of pyiron that
Can get pulled out into a special pyiron utils repo. I'll take care of this eventually, starting with the base logger and singleton code. |
These parts are now available in https://github.com/pyiron/pyiron_snippets so I am going to close this issue. |
So for
pyiron_workflow
I was looking at what mypyiron_base
dependencies actually are, and it's really justSingleton
andlogger
.When it comes to extracting re-usable packages, how small should we go? For instance, singleton's are actually pretty useful, but when I looked on conda-forge for "singleton" there is really not a lot there. The implementation as a decorator is alright, but (a) I like our metaclass paradigm better, and (b) the code hasn't been touched forever so there's minor things like the CI stopping at py3.6.
Does anyone have opinions on pulling
Singleton
(and maybe other stuff?) out as ultra-tiny package(s)?The text was updated successfully, but these errors were encountered: