Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We are now at a point where this is very close to doing everything that was intended and more, I want to start the discussion of how we can publish these to pypi so we can install with regular pip workflows etc.
I had to make a small change to the .toml file as we now have multiple packages within the repo so had to tell the poetry build command what to do.
This works and a whl is produce which can be installed and runs perfectly well.
However it brings us back to an older discussion
Right now when we build the whl we get a single package which includes both the aces package and the apps package.
Including the apps package introduces a lot of web ui dependencies that we do not really want to include if you only want to use the core modules etc.
This would mean we need to do a minor cleanup moving the tests back under the relevent package (sorry thomas i know you had it that way to start), and adding a seperarte .toml file in each package so we can publish the aces package seperate from the apps package
Dragging in all the additional flask related stuff is going to cause conflicts and bloat
This feels like the best thing to do but want to have that conversation
Obviously in that case we cant publish a package called "apps" so we will need to name that?
Then where and under what names do we want to publish these packages?
Ideally once this is working we then extend the CI/CD to get this runnig tests, building and publishing