-
Notifications
You must be signed in to change notification settings - Fork 157
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
win_package: cannot use env-vars (%TEMP%) in path #12
Comments
From @jhawkesworth on Apr 18, 2018 08:49 I don't think it can work like this as the win_package path parameter can take a url or a windows path, so you could get undesirable results if you expanded environment variable names in urls. If you need to use %TEMP% dir you can retrieve it from facts. Like this
|
From @jborean93 on Apr 18, 2018 09:09 @jhawkesworth it could still be doable, we would just need to verify if the value for path is an actual path and then expand if it is otherwise keep it the same as before. |
From @jhawkesworth on Apr 18, 2018 09:48 @jborean93 yep I think we talked about this before and were reluctant to have a 'path_or_url' type, so its still a 'str' in the module parameters. |
From @olenm on Apr 19, 2018 17:49 I can argue either way to have it Thanks! I will attempt the Edit: I would suggest maybe add to the |
From @olenm on Apr 19, 2018 20:29 Well I tried I'll tinker with it later and may file another bug - currently 'fix' is to keep using |
From @trondhindenes on Apr 22, 2018 08:29 Powershell doesn't have the concept of |
From @jborean93 on Apr 23, 2018 08:13 @trondhindenes, we already have this ability in some other modules to automatically expand environment variables enclosed in |
From @jhawkesworth on Apr 24, 2018 07:02 Yeah, perhaps we didn't do a good thing allowing the DOS-style %VAR% syntax for expansion, but I guess it is understood by many. I wonder if perhaps we should/could/already do allow @olenm - feel free to create a documentation pull request regarding explaining that you can't use path expansion currently. I guess if we could parse out the module parameter types this could be automatically added to the documentation pages and then it would be there in the module docs. I wonder if having a path_or_url module parameter type might be useful elsewhere, or whether it would be better to add it just to this module (probably the latter until some other places where it is useful are discovered). |
From @jborean93 on Apr 24, 2018 07:15 @jhawkesworth the good thing about dos style expansion is that we can easily expand it safely with The trouble we have is that win_package allows you to specify the path as a URL whereas we probably should have made that path only and get people to use win_get_url but hindsight is 20/20. |
From @jhawkesworth on Apr 24, 2018 16:13 @jborean93 good point, I was thinking more of playbook readability than safety-of-implementation. |
From @dagwieers on Apr 26, 2018 10:27 There is one problem in the case where the intent is to store a value with the The behaviour may depend on this, but should also be clearly communicated to the user in the module documentation. Does the module allow for variable expansion or not (or conditionally). |
From @shorbachuk on Feb 03, 2019 18:21 Any update or workaround on this? I have a use case and I would like to do something like this:
|
From @shorbachuk on Feb 03, 2019 18:59 I would also add that I am fine with the ${env:var_name} syntax. I've tried the syntax below and it doesn't work: |
From @ShachafGoldstein on Jun 04, 2019 18:01 Why not change it here to expand the vars? - It won't break other use cases that need unexpanded vars and solve it on a larger scale and future uses |
Still an issue. By the way win_get_url handles it correctly. |
From @olenm on Apr 17, 2018 22:12
ISSUE TYPE
COMPONENT NAME
win_package
ANSIBLE VERSION
and
CONFIGURATION
OS / ENVIRONMENT
running ansible-playbook from a mac, remote system is windows server 2016 core
SUMMARY
running win_package with env variables fails (tested with %TEMP%)
STEPS TO REPRODUCE
EXPECTED RESULTS
expected it to dereference the env-variable and run without erroring
ACTUAL RESULTS
Copied from original issue: ansible/ansible#38917
The text was updated successfully, but these errors were encountered: