Can't change quality standard after first write

[vhirtham]

After we write the first asdf file, quality standards can not be changed anymore. This is caused by the asdf interfaces we use and we should probably report it upstream and ask for a modification. I am currently having a look into the code for the exact problem. Maybe I can propose a PR to fix it if it doesn't conflict with their use cases.

However, for us, this is somehow annoying since you need to restart the current environment so that asdf gets reloaded if you want to switch the standard. This directly affects the possibility to showcase some features in the tutorial. Even more annoying is that the different test files affect each other. I had to remove one test since it always failed when I ran the full test suite (pytest). If I just ran all tests of test_config.py, it passed. I tried reload from importlib but that didn't do the trick. If you have any ideas, let me know.

[marscher]

as a first workaround you could try to monkey patch internal ASDF structures. I haven't looked into the details, but this can be feasible until we have a working upstream solution.

[CagtayFabry]

Can you provide a short example for documentation?

From what I understand:

import weldx # (loads asdf and QS via entry points)

add_quality_standard(QualityStandard(qs_dir1))
enable_quality_standard(name=standard1)

# write any kind of asdf/weldx file

add_quality_standard(QualityStandard(qs_dir2)) # does this work?
enable_quality_standard(name=standard2) # this throws an error?

[marscher]

In asdf-2.8 they introduced the new config class, which is also used in this PR. An excerpt from the asdf documentation:

Special note to library maintainers
-----------------------------------

Libraries that use `asdf` are encouraged to only modify `AsdfConfig` within a
surrounding call to `~asdf.config_context`.  The downstream library will then
be able to customize `asdf`'s behavior without impacting other libraries or
clobbering changes made by the user.

Of course we do not want our users to handle this context their selfs, but we need to enclose it somehow and pass in the WeldxFile class. I think it seems like a good idea to have the new Config class store a asdf config object, which gets pulled by WeldxFile every time. This way we ensure we always have the latest config, and we do not interfere with other libs using asdf (which is very unlikely I admit, but we should obey their design principles).

[marscher]

Mhm this problem basically arises from the fact, that we use a global config instance. If we merely bind the config/quality standard to the instance of a WeldxFile, this problem is cured IMO.

I guess this would also simplify the user interface a bit. Since he or she would only need to define which standards to use in the (weldx) Config instance, and the enabling is being done temporarily within the WeldxFile ctor.

@vhirtham I you like, I could try this approach and see if it is useful.

[vhirtham]

Mhm this problem basically arises from the fact, that we use a global config instance. If we merely bind the config/quality standard to the instance of a WeldxFile, this problem is cured IMO.

I guess this would also simplify the user interface a bit. Since he or she would only need to define which standards to use in the (weldx) Config instance, and the enabling is being done temporarily within the WeldxFile ctor.

@vhirtham I you like, I could try this approach and see if it is useful.

@marscher You can try it. Just do it on a separate branch and open a PR targetting this branch.

[marscher]

Can you provide a short example for documentation?

From what I understand:

import weldx # (loads asdf and QS via entry points)

add_quality_standard(QualityStandard(qs_dir1))
enable_quality_standard(name=standard1)

# write any kind of asdf/weldx file

add_quality_standard(QualityStandard(qs_dir2)) # does this work?
enable_quality_standard(name=standard2) # this throws an error?

I think this will work until the second standard does not interfere with the first one in any matter. This is due to the fact that asdf will use both standards to resolve/validate types.

[marscher]

@marscher You can try it. Just do it on a separate branch and open a PR targetting this branch.

will do.