-
Notifications
You must be signed in to change notification settings - Fork 337
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better Environment Variable control in Rex #737
Comments
On platform dictsEDIT: Wrote a lightweight factory / not type. See post below. I really like the idea of the platform dependent dictionary. For example:
If all of you agree I move this in a separate issue to discuss schema handling etc. On value deduplicationDeduplication is shell dependent. As a proof of concept we already have this in The drawback is that it is evaluating logic and you would do this on each append. for /f "tokens=2 delims=:" %%A in ("%%f") Do @Echo %%A https://superuser.com/questions/1407317/how-to-split-variable-by-colon-in-batch The idea is that you set it per variable: "PATH": {
"deduplicate": True,
# ...
}, I am not sure it is necessary to distinguish between deduplication that keeps the earliest, initial (hard as final op) or latest duplicate. I would just go with the earliest for now. Is this sufficient? |
I think this is good. One thing I'd say though is that I found the "parent_variables" terminology confusing. I think it's because 'append/prepend' s being used to mean slightly different things - ie, append as in add a path to the end of a set of paths; but also, append as in, append the SET of pre-existing paths to whatever paths rez constructs. What might be better is "modify_mode" instead (which sits alongside modify_op). Values would be:
Similarly, I think changing all the terminology like "append_all" etc to "after_all", "before_parent" etc would help - it's more intuitive because it describes where an item should appear in a list. Because append/prepend are verbs, it's a bit confusing in the context of multiple different sets of paths (if that makes sense). But these are just terminology quibbles, overall I think the structure and approach is fine. RE deduplication: I would dedup along the way, better that the var value be as expected at all times. I would agree though that keeping earliest value is probably good enough, I really can't think of a case where you wouldn't want that. One thing to consider is what the "parent" value of a var really is. IMO it would be the pre-rez value of the var - but you may have nested rez-envs too, that will have to be taken into account (in that case, I think it should still be the first pre-rez value that is used). A |
(Originated from #707)
Settings and Ops
This is a rather complex topic since we want to support so many use cases so I'll build up to the suggestion based on every possible use case imaginable. It also gives us opportunity to migrate existing settings in a generic configuration.
I don't want to jump into implementation details yet (hope this is doable at all :) ), but let's see if we
can come up with use cases best demonstrated via an sample.
References
#703
#698
#661
(more ?)
Use cases
(cases handled by the sample are crossed)
all_*_variables
Sample
(Note: This is a completely artificial example to showcase many possible use cases)
Naming, features and details are like always up for discussion. Let me know if I missed anything.
The text was updated successfully, but these errors were encountered: