[tg359]

Issues addressed by this PR

Closes #253

Intended as a starting point about which migration to UV as Python venv manager may be tested, and toolkit-specific packages may be handled.

Lots of methods removed, could probably use deprecation/will-be-removed tagging if required, but for now this is intended as an MVP.

Test files

Within the repo are some end-to-end tests, see .ci\unit_tests\Python_Engine_Test\*.sln for running these.

Changelog

Additional comments

[Tom-Kingstone]

I have reviewed as it was requested though I see this is still draft/in progress. Some of these questions will likely still be relevant when this PR is not draft anymore

Merge conflicts should be resolved: git checkout develop, git pull, git checkout Python_Toolkit-#253-Uv_environment_management then git rebase develop, go through the merge process (you might need to fix a bunch of stuff mid merges), then do a force push (git push origin Python_Toolkit-#253... -f)

This will need a Versioning_XX.json file with many messages for deleted methods.
don't forget to also include deleted overload methods from Install.cs and others that don't have direct upgrades.

[Tom-Kingstone]

This looks like it should be ignored by git?

[tg359]

added to gitignore. Typically, you'd keep it in there as it acts as a rulebook against which a uv sync runs to ensure everyone has the same versions of everything - but as we're shipping not just the code, but the environments amidst a wider ecosystem having a little more flexibility can't hurt (until it does, at which point we can stop ignoring the uv.lock file).

[Tom-Kingstone]

These powershell files might do better by using the c# methods you have written to do all these tasks already. (rather than rewriting everything in powershell as well)

see below how to invoke a c# method with powershell

Add-Type -Path "C:\ProgramData\BHoM\Assemblies\Python_Engine.dll"
[BH.Engine.Python.Compute]::VirtualEnvironment("3.12", "Python_Toolkit", $true)

[tg359]

Most of these are leftover from me not using BHoM for this management. I'd be keen to keep a minimal set of them for just-in-case situations where we don't necessarily have BHoM installed but need to run a few things like pytests, docs-generation, removal of venvs. Of course, if they need to be hidden somewhere other than the src/ folder that's good too

[Tom-Kingstone]

Surely you can only get these files by intalling the BHoM? Either way we want to be closer to using BHoM rather than straying away.

They can stay in the Engine/Python folder as that's where we keep all the other python scripts/batch files and setup things anyway.

[tg359]

Surely you can only get these files by intalling the BHoM? Either way we want to be closer to using BHoM rather than straying away.

You can clone the repo without installing 😉 It's mainly for use as a failsafe for the inevitable that happens when an install fails or something breaks and we're without access to the compiled methods. Yes we should be relying on them, but sometimes it's nice to have a backup

[Tom-Kingstone]

How would a non-developer run the test scripts if asked to do so in a test sprint?

Is there a way (from c#) to build the python environment as a dev so they get access to pytest to be able to run the test scripts?

[tg359]

Currently have a C# NUnit test for Pytest methods, which created the dev venv and runs the tests reflecting back to user whatever pytest tells them (hint, a lot of errors currently!). However, I can foresee adding a Run_Pytest method of similar in the future that gets given a venv/toml/similar and searches and runs the pytests for the person asking

[tg359]

I have reviewed as it was requested though I see this is still draft/in progress. Some of these questions will likely still be relevant when this PR is not draft anymore

Merge conflicts should be resolved: git checkout develop, git pull, git checkout Python_Toolkit-#253-Uv_environment_management then git rebase develop, go through the merge process (you might need to fix a bunch of stuff mid merges), then do a force push (git push origin Python_Toolkit-#253... -f)

This will need a Versioning_XX.json file with many messages for deleted methods. don't forget to also include deleted overload methods from Install.cs and others that don't have direct upgrades.

I've made most of the changes suggested, so it's ready for another review now. Two main things - the Versioning I'm not sure about whether it'll work or not, I leant heavily on co-pilot to help with that alongside the outdated 7.X documentation for Versioning on BHoM.com/whatever-it-is, and the location of the versioning_XX.json file is currently root so that may need to go somewhere else.

I also took a look at the dockerfile. I've no way of testing it, but I tried to make it work a little better with UV. Let me know what you think.

[bhombot-ci]

Please be advised that the check with reference 125694657245 has more than 50 annotations of notes. API limitations restrict annotations to 50. You may need to rerun this check to obtain the next set when you make changes. At the time of reporting this check, there are 55 additional annotations waiting, made up of 55 errors and 0 warnings.