Seeking clarifications

[materialsproject]

Seeking clarifications

[shyuep]

• Drawbacks - too many to list.
• General suggestion is that pymatpro should be a thin layer. Everything that can be "outsourced" to public packages should be so. If pymatgen-db already has a db access, improve on that rather than writing your own in pymatpro. If builders need a "workflow" style process, use fireworks. The more code is public, the more eyes will look at the code. The reason why pymatpro is the way it is today is because privacy promotes laziness. There are no tests, people write all sorts of things badly, and no one ever looks at them.
• Dependencies - use as many public, well-maintained code bases as you like. The more, the better.

[dwinston]

I agree with @shyuep on shunting MP-specific stuff to public packages. The idea of this public repository specifically is to shunt materials-science-agnostic stuff from pymatgen-db so that more eyes look at the code that essentially just builds on pymongo to manage database building and maintenance -- I couldn't find a good open library for this, and the audience is anyone who uses Mongo and Python (like https://github.com/materialsvirtuallab/flamyngo).

The idea of https://github.com/materialsproject/emmet is to trim pymatpro and outsource stuff to a public repo. emmet should depend on this repo and on pymatgen-db, etc. (emmet:maggma as atomate:fireworks).