Implementation of Job class

[JohannesGaessler]

This PR adds an implementation for the Job class and its sub-classes.
I also laid some groundwork to be used for serialization in general.

• Implement Job.
• Implement JobSchedulingConstraints.
• Implement DockerContext
• Implement DockerConstraints
• Add unit tests.

[nikolatzotchev]

How will we generate the uid, i fount this online, but maybe we can just start with 1 and increment for each new job.

[nikolatzotchev]

"If the job has not been queued yet, it has no UID." aa I see.

[nikolatzotchev]

@JohannesGaessler I wanted to ask, what IDE are you using?

[JohannesGaessler]

I am using PyCharm Community Edition.

[nikolatzotchev]

Do you know how to run every test in a dir, I tried also in the terminal using

python -m unittest discover <test_directory>
but it runs 0 test, the same in pycharm.

[nikolatzotchev]

To me everything looks good, all test are ok. I don't have a lot of experience with python so it will be good if other people check it as well.

[JohannesGaessler]

Do you know how to run every test in a dir, I tried also in the terminal using

I usually just do it via setup.py
I pushed a fixup where I quickly threw something together.
To run all tests, run python setup.py test

[ammen99]

Neat. It took me awhile to figure out why __eq__ is needed, but it definitely makes sense for unit tests.

[ammen99]

Ready for merge, just squash the fixup commits.

[nikolatzotchev]

Can we merge this pls.

[ammen99]

Good that this wasn't merged, I completely forgot to check.

The unit tests do not pass MyPy checking, and I think our tests should be strongly typed, just as our code is. I'll also add the corresponding checks to my CI pull request.

[JohannesGaessler]

Do we really need type safety for our unit tests?
The whole point of type safety is to prevent unforeseen runtime errors.
This makes no difference for unit tests since runtime errors would cause your unit tests to fail so you would notice immediately.
However, if I wanted to make the unittests type safe I would no longer be able to use the mixin approach that I am using now.
The problem is that when you import a subclass of unittest.TestCase the unit tests of that class will be executed in your test suite as well.
As a consequence inheritance like JobTest -> SerializableTest -> TestCase would be a giant pain to implement unless you resort to copy-pasting code.

[ammen99]

Do we really need type safety for our unit tests?
The whole point of type safety is to prevent unforeseen runtime errors.

I am using an IDE (rather vim + plugins) where type safety helps me use autocomplete and also catch errors while I am typing. Hence I'd like to use type safe code everywhere.

Seeing that the type is wrong can help you realize your mistake faster if the test fails.

The problem is that when you import a subclass of unittest.TestCase the unit tests of that class will be executed in your test suite as well.

Right, we can make an exception for the mixin class. Just add # type: ignore at the top of the python module for the mixin class. (found it here python/mypy#545 and it seems to work on my computer)

seems like it doesn't work for when you try to import the class in other modules, I'll try to see how that can be fixed.

Final test: you can add @no_type_check to the methods of the mixin class so that they are not type-checked. This does not seem to affect the rest of the code.