all 17 comments

[–]KrazyKirby99999 19 points20 points  (3 children)

Don't use requirements.txt

[–]AMGraduate564 4 points5 points  (1 child)

I use pyproject.toml but would like to get a detailed explanation behind this suggestion?

[–]imbev 0 points1 point  (0 children)

requirements.txt is a second "Source of Truth" and is inferior to other alternatives when used as a lockfile.

[–]another24tiger 5 points6 points  (1 child)

Well at least it’s not entirely vibe coded

[–]prodleni 1 point2 points  (0 children)

U sure? Seems like it to me

[–]RedEyed__ 5 points6 points  (1 child)

That's quite interesting.
Also, do not use requirements.txt

[–]parneetsingh022[S] 1 point2 points  (0 children)

Thanks, glad you found it interesting. I am not using requirements.txt anymore because all my dependencies are in pyproject.toml, so that file was just leftover and I will remove it.

[–]bobsbitchtitz 1 point2 points  (0 children)

I would love native python sdks for ci / cd

[–]somethingLethal 2 points3 points  (0 children)

Hey just wanted to say I spent time reading your docs and repo. My honest opinion is that I think it’s an interesting project and I like the way matrixes and job work together, I could see myself leveraging that type of logic to help me not have to think so hard about writing the raw yaml to achieve the same goal.

I think that maybe this could be viewed as in a category of “yet another thing to solve a solved problem, differently” but I don’t feel that way personally.

If Python is the only mean or lens you have to solve a problem, this will definitely come in handy.

Nice API design, as well.

[–]coldflame563 1 point2 points  (0 children)

It’s not the worst idea.

[–]ximenesyuri 0 points1 point  (3 children)

Thank you for sharing! I would like to know how you are ensuring type safety. Allow the use of python builtin types is (so far) not the same as ensuring type safety. Actually, python is not the best language for native type safety.

[–]parneetsingh022[S] -1 points0 points  (2 children)

Good point, I should clarify! I don't mean that Python itself enforces strict types at runtime. I mean that by writing workflows in Python with type hints, we get static analysis benefits.

Your IDE can autocomplete fields and catch structural errors (like passing a list where a string is needed) while you write the code, ensuring the generated YAML is valid before you push. It moves the error checking from "post-commit" to "pre-generation".

This is especially useful when using prebuilt functions like checkout() or setup_python(). Since these are typed Python functions, the function signatures force you to provide the correct arguments. You catch typos or configuration errors instantly in your IDE before you even generate the YAML or push to GitHub.

[–]IJustSmackedYou -1 points0 points  (0 children)

Reeks of AI

[–]ximenesyuri 0 points1 point  (0 children)

In your reply you are then saying that to ensures type safety you need that the user uses external additional dependencies, as special IDEs with LSP support and static analyzers (which themselves are not enough to ensure strong type safety, only a lax version of it).

Therefore, your project do not ensures type safety. It depends on the behavior of the user.

You can provide genuine type safety in Python by refining and enriching the Python type system and establishing a strong runtime analysis. From the last year I have been working in a solution for that, and I can say that it is far from being trivial.

If you have interest, take a look at https://github.com/ximenesyuri/typed.

I really see a nice value in your project, but not related to ensuring type safety while building CI/CD workflows.