multiple equal Code labels/names, problem?

[broeder-j]

Is there a reason why code labels should not be unique?

In my opinion:
either AiiDA should not allow in 'code setup' to save a code with a certain label if that label is already in the database (enforce code label uniqueness),
or all methods like get_code_from_string(codename) should take per default convention the 'newest code' if not unique. Maybe bad idea, you also have to think about import of other databases.

(In general if you import data, you might 'break' the provenance in a sense that you cannot execute the code/workflows anymore, which generated the original data, but you also do not want to use a different "Code" node with the same name without knowing.)

I guess this might be a small problem for materials cloud, because if you have two times 'pw@cluster' in you database you cannot run some of your QE workflows with that code anymore.

Therefore, code label handling is bad use in workchains/workflows.

But maybe there are reasons not to do so and you have a different opinion on this.

(we had a setup script for the database in our tutorial and a lot of people executed that several times, which made everything with code labels not work. But sure the script could have been smarter.)

[lekah]

Hmm, that's an interesting case.
In my opinion, code labels (as labels in general) are there for convenience, the unique identifier is the uuid (which you could also pass to the workflow instead of the label).
The main problem seems to be not that the code label is not unique, but that one is tempted to pass a code label to a workflow. As far as I know, we have made the decision to move towards a design where Code is treated like Data, which means that there's nothing preventing (in principle) a Code-instance being input to a workchain. In that way there's no collision due to label. Would this have solved the problem you saw?
@muhrin Is it possible to have Code as input to a workchain?

[broeder-j]

Yes. Sure the workflows/workchains are written with code nodes (which works fine by the way).

But the way you get the code in your 'script'/'notebook' to run stuff, the labels are there for convenience. So what I pointed out above is, that the scripts that you write to generate data.
If that convenience doesn't work in a later phase, there is no point in getting codes by the label at all.

But this is a minor thing over all, it will show up if you work on several DBs and share data with others. How annoying it is, we will see.

[broeder-j]

By the way:
Currently 'verdi code update/show/... pk' ends up in an error. it only works with the name.
Which also means that if you have two codes with the same label. these commands won't work any more.

[giovannipizzi]

Good point. But that's actually a bug that was introduced when refactoring the get_from_string() function. I'll try to see if I manage to fix it soon.

[broeder-j]

I know. just wanted to point it out, in case you are not aware

[sphuber]

I will open a new issue #536 that will only address the problem when passing an integer pk to verdi code.

[giovannipizzi]

I will keep this issue open for further discussion, but I think it's in principle ok to have multiple codes with the same name, even if not convenient.

I keep this open because we should instead encourage people to pass the Code node itself rather than the code label to any workflow they write. In particular, we should improve our examples, and make sure we can pass a code as input to workfunctions/workchains ( @muhrin is this already possible?)

[broeder-j]

Yes, it is possible to parse a code to a workchain.

[giovannipizzi]

Then, I think we can even close the issue, if you agree. I will add a different issue to the aiida_demos repo.