Open dan-escott opened 7 years ago
Convert $collection_uri and $proj_uri to local variables within whichever method they are needed, and populate their values using global functions to avoid code duplication.
Looks like a lot of work. Also, it defocuses from the task in question.
Add an explicit method to initialize the global variables based on current $global:tfs settings.
This is probably how it should work. Feel free to PR.
Thinking about it more, I actually favour replacing the global variables with global functions as this ensures that the values in the $global:tfs object are actually the ones being used. This only requires a pair of brackets being added to each of the places that currently consume $collection_uri and $proj_url, so should not detract from the task.
I hope I'm not missing something here, but it seems like there's no (nice) way to change the TFS team project or root URL once the TFS module is imported into a PS session.
Looking at the source:
In my case I've run into issues where the TFS module was loaded because it was listed as a required module in another library I was working on. This caused the module manifest to be invoked earlier than I expected and before I'd set $globals:tfs (easy to workaround once I'd debugged and understood the issue). I also have a need to work with multiple projects.
Forcing a re-import of the module will work, but it's somewhat confusing that the values of $globals:tfs are not necessarily the ones that are being used. It's also difficult to work out when it's necessary to re-import in some more complex automated scenarios.
Can I suggest either:
I'm happy to create a pull request with either of these implemented if you think it's worth pursuing.