Two JobFactories?

[niklassiemer]

We currently have two JobFactories in https://github.com/pyiron/pyiron_base/blob/7101ea78d8c9689c2b8b38cdbb9796cfe4601514/pyiron_base/job/factory.py#L118 and https://github.com/pyiron/pyiron_base/blob/7101ea78d8c9689c2b8b38cdbb9796cfe4601514/pyiron_base/job/jobtype.py#L130.

While the first one implements a call and is used in base_tools, the second one is actually used in the Creator and, thus, responsible to handle pr.create.job Is there a particular reason we have these two different classes?

I really would like to streamline all job creation through one JobFactory with one implementation of JobType along the lines

class JobType:
    _job_class_dict = {}

   def __new__(cls, ...):
        # same as now

    @classmethod
    def register_job_types(cls, job_class_dict):
        for job_name, job_class in job_class_dict.items():
            if job_name not in cls._job_class_dict:
                cls._job_class_dict[job_name] = job_class
            else:
                raise ValueError(f'Name clash. A job with name "job_name" already defined!')

such that we can handle our current JOB_CLASS_DICT as a class attribute on the JobType.

[liamhuber]

I would also like to only have one (or at least one parent that has the call functionality and gets inherited from). I'm afraid I won't be able to deal with this for the next couple of months though. I think the root of the issue is the Creator vs toolkit mentality. I much prefer toolkits (even if we somehow maintain a creator that gets toolkit elements dynamically loaded onto it) because the Creator path currently leads to reimplementing Project in every pyiron submodule.

[liamhuber]

Oh also I'm pretty sure I want tp get rid of JOB_CLASS_DICT altogether as it uses string based links to the objects instead of real object links, which is hell for IDEs and is prone to errors leaking in when we rename or move stuff

[liamhuber]

Ping @liamhuber