Liam Huber

As of the meeting today we decided that this is a fine idea. Any bits of pieces of pyiron that - Depend _only_ on the standard library - Get used...

> Alternatively, we could increase the limit from 50 to 256, that should keep us save. Only heuristically -- albeit to a very high probability. Nonetheless, in this case I...

I don't think it's a problem that you say "please don't use these features" but your config file still has parameters available for utilizing those features in case you re-activate...

> > Since you do not define any project_paths in the config that should be an empty list... > Aha aha aha! My comment over on the issue is also...

> I can see the advantage of being able to switch from no database to a local database, but at least for the current case I just want to support...

> And the second part is that the `sql_*` keys are confusing when I did not configure them. In particular when users try to run pyiron without database. That is...

> It is confusing for the user I'm sorry Jan, but I really struggle to see what's confusing. The defaults are there even if you don't specify values for them...

> See our [minutes](https://github.com/orgs/pyiron/teams/pyiron/discussions/97/comments/6). Nice! Very detailed 😄 I would push back on one point. *But* since #578, which used to do exactly this point now does something different (and...

Yeah, that solution sounds great. No overwriting separate sections involved, just ignoring them. We need to provide *somewhere* for users to view the inactive settings inside a notebook environment, but...

> If you want to be exactly sure not to cause issues, change [this workflow](https://github.com/pyiron/pyiron_atomistics/blob/main/.github/workflows/deploy.yml) to not unpin pyiron_* deps (the line with sed), release a new version then do...