majkinetor / TFS

Powershell module to drive TFS 2015+ via REST interface
MIT License
16 stars 6 forks source link

Cannot change team project or root URL once module is imported #6

Open dan-escott opened 7 years ago

dan-escott commented 7 years ago

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.

majkinetor commented 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.

dan-escott commented 7 years ago

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.