Rename `pyiron_snippets`

[jan-janssen]

As we are currently in progress of renaming pyiron_vasp to vaspparser pyiron_snippets is the last remaining package which uses the pyiron_ prefix but does not depend on either pyiron_base, pyiron_core or pyiron_workflow. I do not have a specific suggestion for a new name, so maybe this issue can just start the discussion.

[liamhuber]

When creating the repo, I tried looking for more generic names like "snippets", but everything I looked for was taken already.

Here, I think we might reasonably live with the prefix. The concept being that it's a bunch of independent snippets, written by the pyiron team and particularly useful/used in pyiron repos.

The main benefit I see from removing the prefix has been that users don't think they need base+... to use pyiron_*. As we have shifted away from the prefix on a critical number of packages, I think the threat of this is less.

[jan-janssen]

When creating the repo, I tried looking for more generic names like "snippets", but everything I looked for was taken already.

I agree, I currently also do not have a better name in mind.

Here, I think we might reasonably live with the prefix. The concept being that it's a bunch of independent snippets, written by the pyiron team and particularly useful/used in pyiron repos.

The argument written by the pyiron team applies to all the code hosted in the pyiron Github organization. And I do not see the snippets restricted to pyiron repositories specifically.

The main benefit I see from removing the prefix has been that users don't think they need base+... to use pyiron_*. As we have shifted away from the prefix on a critical number of packages, I think the threat of this is less.

The illusion could be that people believe these are snippets to use pyiron_base or pyiron_workflow more effectively.

Based on this I am still in favor of renaming the package, but as I do not have a better name, let's keep the current name for now until we find a better name to prevent the number of name changes.

[pmrv]

Actually plain snippets does not appear to be taken. The nuclear option would be to disband the package and put out smaller ones for the components. With @liamhuber centralized CI and LLMs writing actions, I think the marginal cost for this is actually low, but I'm also not particularly incentivized, since snippets just works™ so far. logger is likely the only part of snippets that's actually tied to pyiron infrastructure.

[liamhuber]

So it is! Wild, I wonder what gave me the idea it wasn't. Yeah, I'd be totally open to renaming it snippets and making a 1.0.0 release.

Breaking it apart has the advantage that if we break backwards compatibility, we only need to bump a version number for the relevant package. On the other hand, some of the modules are reeeaaally small to be their own package, and since we insist on no dependencies, they all have that in common. At the end of the day I'm totally fine with either route.

[liamhuber]

renaming it snippets and making a 1.0.0 release

2.0.0 -- we're already on v1