-
Notifications
You must be signed in to change notification settings - Fork 72
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
add profile case transformations to "aws-sso-util configure populate" #48
Conversation
Sorry, but I can't accept this. I understand the pain point, but I'm not willing to put |
Understood. That crossed my mind as well :^) It's safe enough in my use case, but I understand. I'll come up with an alternative plan. I'd rather do something that can get merged into your baseline than maintain a fork. |
Do you have a sense of what transforms would be useful? You've got lowercasing in the example, but that's only one. Another potential avenue is allowing arguments to the transform script to be passed through the |
Hi, Ben. Thanks for following up! My use case is really just lowercasing, but I thought something more flexible would make for a better feature. I just updated my branch to do something long those lines, so with it now, you can specify
|
This is more reasonable. I'll have to think about it some. I'm preparing a release now, so it would go in the next one. |
Sure. I’m sure you’re more than capable, but let me know if you’d prefer it a bit different. Happy to adjust it. I just wanted a nice way to lowercase my profiles at a new job without writing my own solution again. Quite pleased you’ve share this — I hadn’t come across it until just recently. One thing I debated was aligning the arg name and method with the trim features, or aligning it with the safe-account-names feature. The method I chose, replicating how you implemented the trim features, lets us chain transforms, so there’s a future for more powerful capabilities later (even though the current set of choices don’t do much to take advantage of that). |
I'll keep pondering on it. It's a worthwhile request, the profile name process means you have to construct the entire profile name yourself, as an escape hatch it's a lot of work. Here's another idea: what if there was an |
Yeah, that could be a nice solution, too. That sort of thing is actually where my unix-brain went first... "a way to pass the profile name through sed would be really convenient," and |
Ok:
|
Nobody but the chaos monkeys. I just put that one in for fun ;-) |
Pushed an update. New help message includes this:
|
In my last commit, I added the output from |
…pulate" which provides a way to evaluate Python code against profile names that are built from components, giving a CLI middle ground between trimming regexes and invoking a separate script
(mostly based on Python string functions) From the update to the docs, transforms include some common Python string methods: * `alnum` * `ascii` * `capitalize` * `casefold` * `lower` * `swapcase` * `title` * `upper`
57cd624
to
4503a2c
Compare
based on feedback in benkehoe#48
Add yourself to |
based on feedback in benkehoe#48
6af75d7
to
7392b32
Compare
thanks! |
386a33d
to
93dc226
Compare
Last thing, change the target for this pull request to be the |
you got it. thanks for all the dialogue on this, ben. |
…#48) This provides a way to modify the profile name components for a common use case without having to resort to --profile-name-process
This has been released in v4.27. Thanks so much for it, it was a great idea! |
fantastic! ✋ thanks again for engaging so much on it. i hope others find it useful as well. |
which provides a way to evaluate Python code against profile names that are built from components, giving a CLI middle ground between trimming regexes and invoking a separate script