pyinfra v3 WIP #996
pyinfra v3 WIP #996
Conversation
Fizzadar
force-pushed
the
v3
branch
5 times, most recently
from
233ce3a to
1bd88f9
Compare
Fizzadar
force-pushed
the
v3
branch
2 times, most recently
from
83ba17e to
5e476f1
Compare
Codecov Report
@@ Coverage Diff @@
## 2.x #996 +/- ##
==========================================
- Coverage 91.61% 90.24% -1.37%
==========================================
Files 127 129 +2
Lines 8180 8222 +42
==========================================
- Hits 7494 7420 -74
- Misses 686 802 +116
|
Fizzadar
force-pushed
the
v3
branch
2 times, most recently
from
3d83c38 to
eee7d7c
Compare
|
Hey @Fizzadar, after getting increasingly frustrated with Ansible over the past months, I was researching alternatives and found PyInfra. I'm inclined to try it out, but I noticed this draft PR which seems to suggest V3 is being actively worked on. Can you elaborate how much V3 will differ from V2 in terms of API? How smooth will the migration path from stable to V3 be? In other words: is it safe start using the stable version of PyInfra right now with a relatively smooth upgrade to V3 once it hits? I'm also interested in contributing. I saw that there are no Docker/Docker Compose related operations yet, and I need those. But it would be a problem if the API is going to change significantly and operations need to be changed a lot for V3. Could you elaborate? |
Hi @DonDebonair! Apologies for taking ages to respond here. Ultimately for the public stuff (ie anything in the docs) there should be no significant changes. Any changes will display a warning in v2. The majority of v3 changes are in the CLI (approval step by default) and internal APIs. I am intending for v3 to provide official support for API usage as well (which v1 had). So in short: migration between v2/v3 should be trivial in almost every case, any changes needed will show as warnings in v2. Final thing - for operations there’s no significant change to those APIs so any ops designed for 2 will work in 3 (and any contributions would be very welcomed on both versions!) Hope this helps! |
|
Hey @Fizzadar thanks for the response! I will start using PyInfra then. Do you want new operations - like for example ops to manage docker containers and images and interact with docker compose - to be part of this repo, or should they live somewhere separate? When I'm ready to contribute, I can make a PR to this or another repo |
Fizzadar
force-pushed
the
v3
branch
4 times, most recently
from
be95209 to
cf7955c
Compare
|
Github please will you run the workflow! |
Fizzadar
force-pushed
the
v3
branch
2 times, most recently
from
ccce6d7 to
81d71f2
Compare
This should enable type checking user code calling deploy wrapped functions better, but means the wrapper has to be called `@deploy()` style.
Never used and now in v3 will become impossible to implement, which is just fine since performance has pushed along in other areas.
Not my finest moment!
This is no longer required with the v3 eval-facts-at-runtime changes!
This is no longer required with the v3 eval-facts-at-runtime changes!
* Add types to get_fact and some facts * Fix typing on default `FactBase.process` return value * Fix mypy errors * Inline metaclass=FactNameMeta * Add types to get_fact and some facts * import TypedDict if TYPE_CHECKING * typing.Literal new in Python 3.8 * FactBase[Optional[str]] if TYPE_CHECKING * Fix remaining type issues * Remove unused imports * Final type fixes for older Pythons * Final final fix * Skip operation error test on Windows The operation itself isn't available on Windows `@local` targets. --------- Co-authored-by: Nick Barrett <[email protected]>
No description provided.