-
Notifications
You must be signed in to change notification settings - Fork 365
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
Path rewriting for setenv:
and build-env:
#5636
Conversation
Updated |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but... where is the doc ?
In it it may also be appropriate to mention the reason for an x-*
field (the manual specifies that it's normally for external tools IIRC)
To not change the opam file syntax, opam need to use it's own external tool features ^^ |
2028e26
to
7365526
Compare
Doc updated! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm just testing locally with the various packages that everything continues to work as needed, but I'm not expecting to find a problem, thank you!
Various suggestions, most of them documentation/comments, but it's looking lovely 🙂
src/client/opamAdminRepoUpgrade.ml
Outdated
envu_comment = None; | ||
envu_rewrite = empty; | ||
}] |> | ||
(* XXX Rewrite rules ?? *) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Stray comment?
src/client/opamAction.ml
Outdated
envu_value = OpamFilename.Dir.to_string cygbin; | ||
envu_comment = Some "Cygwin path"; | ||
envu_rewrite = empty; | ||
}] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that this happens a lot, worth having OpamBaseTypes.env_update
:
let env_update ?comment:envu_comment envu_var envu_op envu_value rewrite =
let envu_rewrite = match rewrite with
| `resolved -> Some (SPF_Resolved None)
| `unresolved -> Some (SPF_Unresolved (Empty, Empty))
| `rewrite r -> r in
{envu_var; envu_op; envu_value; envu_comment; envu_rewrite}
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in a commit
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't know which version is more easily readable
[{ envu_var = "PATH";
envu_op = EqPlus;
envu_value = OpamFilename.Dir.to_string cygbin;
envu_comment = Some "Cygwin path";
envu_rewrite = empty;
}]
vs
[ OpamTypesBase.env_update_resolved ~var:"PATH" ~op:EqPlus
~value:(OpamFilename.Dir.to_string cygbin)
~comment:"Cygwin path" () ]
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry - looking at it again, I now realise that I'd forgotten that a GADT was involved and that we can't convey that in optional parameters! (yet... it's been on my wish list for quite a few years...)
Wouldn't it be OK not to label those three arguments, though> I think env_update_resolved "PATH" EqPlus (OpamFilename.Dir.to_string cygbin
quite clearly conveys what it's doing to give:
[ OpamTypesBase.env_update_resolved ~comment:"Cygwin path"
"PATH" EqPlus (OpamFilename.Dir.to_string cygbin) ]
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It is possible. The labels came at first because of var & values are string, and like that there is no confusion between them.
I'm ok to remove them and have then
val env_update_resolved:
?comment:string -> ?rewrite:spf_resolved separator_path_format option
-> string -> env_update_op_kind -> string
-> spf_resolved env_update
d288ab4
to
611f497
Compare
type env_update = { envu_var : string; envu_op : OpamParserTypes.FullPos.env_update_op_kind; envu_value : string; envu_comment : string option; }
It contains rewriting rules of the environment variables to update: - not a path, no rewrite - formulaes to resolve to retrieve separator & path format - resolved formulaes, directly separator & path format This commit contains only the addition of the field, it does not performs the rewriting.
…ewriting rules for variables defined in `setenv` and `build-env`. Format is x-env-path-rewrite: [ [ VAR false ] # no a path, no rewrite [ VAR ":" "target" ] # always use ":" and target format [ VAR (":" | ";" { os=win32 }) ("target-quoted" | "target" { os = win32}) ] # On windows use ";" separator and don't quote, otherwise ":" and quote the set/added path if needed. ]
It keeps backward compatibility. Format is then: | VAR OP VALUE | VAR OP VALUE COMMENT | VAR OP VALUE norewrite COMMENT | VAR OP VALUE norewrite | VAR OP VALUE SEPARATOR PATH-FORMAT | VAR OP VALUE SEPARATOR PATH-FORMAT COMMENT
…t per variable) to compute environment updates
Thanks! |
Add environment path rewriting for Windows, see spec for more details.
New
x-
fieldx-env-path-rewrite
to define rewriting rules, in the format:IDENT <bool> | (<separator-with-filter-formula> <format-with-filter-formula>)
listhost
will callcygpath
on the added path on windows.*-quoted
will quote the added path if it contains the separator.target
, if given explicitly will rewrite slashes in bacwardslashes.It has an effect on
environment
file, as it needs to store the resolvedseparator
andformat
, but it remains backward compatible:todo:
x-env-path-rewrite
Old Version
Implementation of proposal described in #5602
+ add lint to check that the
x-
field is well defined+ add lint that check that if
x-
field is true, an opam-version availability guard is settodo: