This PR focuses on running Origen from various invocation contexts. The current tests assume a development environment, poetry being available, a pyproject, etc. and failure to meet that led to issues.
This PR remedies that and adds some elementary tests that setup Origen in the various invocation contexts. I highlight "elementary tests" though - basically just tries to eval some simple statements - but the frameworks are there and more coverage can be added later. They're a bit hacky in some places - I understand the hacks and why they're needed and left some notes with some TODOs to revisit, but I'm not exactly sure how to best clean up and I'd rather come at that from the "we have tests, let's make them less hacky" than "we have no tests".
The only one that irks me is a poetry/pip (not sure since Poetry uses pip) issue on Windows where a pyproject can't have local dependences on a drive different than the pyproject's. It's fine on Linux, but I don't have a good setup currently to look at this. It's also not new - only that it's just now being noticed from these tests. The workaround uses some hard-coded stuff though because I can't get GA to do what I need, despite what I see in the docs. Will keep looking at it but it’s a clean-up item. Ideally, the problem of pyproject dependencies on different Windows drives will be solved and this will be moot anyway.
Getting back to the invocations, the contexts I'm referring to are:
1) In-App: basically test_apps/python_app
2) Workspace: basically test_apps/no_python_app
3) User-Install: mirrors O1's user installations
4) Global-Install: mirrors O1's tool-repo installations
5) No Workspace: no pyproject and can't use poetry. Essentially the install you'd get if you just install the packages directly using pip.
origen.status will hold the type of invocation, the pyproject path (if applicable), and the CLI root. The first is an enum, defined here.
Plugins and command extensions are supported in each context.
Below is a summary of the major updates:
Update run commands to handle more global invocations, with no, implicit, or explicit pyproject.
Support invocation and CLI location tracking, available in the status.
Added _origen.infrastructure module. More esoteric than OM's framework module, so renamed to infrastructure to avoid confusion.
Support finding origen.tomls in workspace setting by searching up to the root (similar behavior to if run in an app) but without the config dir.
Change executable name from o2 to origen when installed via pip/poetry.
Support running from scripts (files) in origen eval. Maintains the same locals/globals, as if all were run as the same program, but gets around some annoyingness caused by poetry and pyenv eating escape characters (when origen is launched through those means).
Alternative to needing crazy things like r"print\(\\\"Origen\ Status:\\\"\) print\(origen.status\)" to run from the command line.
Arg/opt indices are now available in the current command. Possible, when needed, to discern the argument order, except for flag-opts - per clap's docs.
This is the another development piece I need for "origen as tool platform". Next pieces:
Work on release procedure.
Need similar tests for how origen.tomls are handled in each context. Should follow pyproject, but currently not tried - and by extensions, not tested for.
Once I start doing some internal usage with O2 though, if this is broken, it'll pop up real quick.
Hello,
This PR focuses on running Origen from various invocation contexts. The current tests assume a development environment, poetry being available, a pyproject, etc. and failure to meet that led to issues.
This PR remedies that and adds some elementary tests that setup Origen in the various invocation contexts. I highlight "elementary tests" though - basically just tries to eval some simple statements - but the frameworks are there and more coverage can be added later. They're a bit hacky in some places - I understand the hacks and why they're needed and left some notes with some
TODOsto revisit, but I'm not exactly sure how to best clean up and I'd rather come at that from the "we have tests, let's make them less hacky" than "we have no tests".The only one that irks me is a poetry/pip (not sure since Poetry uses pip) issue on Windows where a pyproject can't have local dependences on a drive different than the pyproject's. It's fine on Linux, but I don't have a good setup currently to look at this. It's also not new - only that it's just now being noticed from these tests. The workaround uses some hard-coded stuff though because I can't get GA to do what I need, despite what I see in the docs. Will keep looking at it but it’s a clean-up item. Ideally, the problem of pyproject dependencies on different Windows drives will be solved and this will be moot anyway.
Getting back to the invocations, the contexts I'm referring to are: 1) In-App: basically
test_apps/python_app2) Workspace: basicallytest_apps/no_python_app3) User-Install: mirrors O1's user installations 4) Global-Install: mirrors O1's tool-repo installations 5) No Workspace: no pyproject and can't use poetry. Essentially the install you'd get if you just install the packages directly using pip.origen.statuswill hold the type of invocation, the pyproject path (if applicable), and the CLI root. The first is an enum, defined here.Plugins and command extensions are supported in each context.
Below is a summary of the major updates:
_origen.infrastructuremodule. More esoteric than OM'sframeworkmodule, so renamed to infrastructure to avoid confusion.origen.tomls in workspace setting by searching up to the root (similar behavior to if run in an app) but without the config dir.origen eval. Maintains the same locals/globals, as if all were run as the same program, but gets around some annoyingness caused by poetry and pyenv eating escape characters (when origen is launched through those means).r"print\(\\\"Origen\ Status:\\\"\) print\(origen.status\)"to run from the command line.This is the another development piece I need for "origen as tool platform". Next pieces:
origen.tomls are handled in each context. Should followpyproject, but currently not tried - and by extensions, not tested for.