Host as part of Argo Labs about argo-python-dsl HOT 10 CLOSED

Thanks @alexec, much clearer now! 👍 and sounds good to me!

I would say we're even pre-alpha. I am doing my best to keep it up but with the prospect of holidays knocking on the door, let's give it some time to settle down and see how people react to the SDK, what do you say? :)

We'll put the pieces together and maybe we can then migrate even more of our tools if you're down for it 😬 It's all about building the community, after all.

Cheers,
M

from argo-python-dsl.

Hello @alexec !

Thanks for the invitation :) I'd very much like to raise awareness about the tools. However, I am currently not sure about transferring the repository. We've been building tooling around Argo and there are some links between the individual tools + we need to iterate quickly.
Another thing is that I have mixed feelings about the Argo Labs organization from the look of it.

Maybe you can help me with the decision:
What is the status and the official statement about Argo Labs? Is it this organization: https://github.com/orgs/argoproj-labs/people?
I don't see any members, there's no site, no description. Honestly, it doesn't look like it has much of traction to it and I haven't found a statement about that organization on the official argoproj page.
Is it considered a staging environment for the official argoproj org?

Any drawbacks of transferring the repo under that organization? What're the organization settings? Will I be able to use GitHub Actions?

Thanks again!

Cheers,
M

from argo-python-dsl.

That's odd, I see 10 members on that page. Presumably they are hidden - but you have a good point around information, we could probably do a better job on that front. It is intended as a place for project to start out and potentially migrate to a top-level project later on, as well as a place for community projects to mature.

Probably the best example of a successful Labs project in the Argo CD operator:

https://github.com/argoproj-labs/argocd-operator

If you think you're still in a beta phase, then it may not be the best time to migrate.

Regarding restrictions, I can't think of any of the top of my head.

It terms of other benefits, we don't use Github Action at the moment, all project build on Circle CI, but I don't see any reason not to use them.

from argo-python-dsl.

We're want to introduce an SDK for v2.6. This will require you to be running the new Argo Server. We've just started to cut some PoC level code, it'd be great to get your input on it:

https://github.com/argoproj-labs/argo-python-sdk

from argo-python-dsl.

@alexec Hello there! Isn't this the same thing as https://github.com/CermakM/argo-client-python?

from argo-python-dsl.

I'll also generate the new models ASAP for the argo-client to match the models from 2.5.

TBH it quite surprises me that you've created that repo and named it exactly the same way as this one. This really doesn't feel like you're open to collaboration, more like "either you move the SDK to argoproj-labs, or we do that ourselves from scratch". Also, it doesn't exhibit good open-source behaviour in my opinion. Please, correct me if I am wrong (I might be, this is just how I feel about it and feelings are deceiving ☺️ ).

I would personally see as a much more suitable solution for argoproj-labs to fork these repositories as downstream and contributed upstream.

Anyway, I do want to build a community and I do want to advance this SDK further, so perhaps we could consider migrating both of these repositories?

Problems to solve beforehand: I am also maintaining argo-workflows, how would we go about that one?

Cheers,
M

from argo-python-dsl.

Hi @CermakM ,

I hope you understand that is not my intention at all. ArgoProj Labs is a place for experiments and growing ideas to share and help grow the community. People who own repos are admin on those repos, but also get the benefit of being close to the core code.

The repo is very much a PoC and was generated by using swagger codegen from brand new and as-yet unpublished Argo Server APIs coming in v2.5. The expectation is that we'll need to create SDKs for several languages , such as Java and Go, and maintain multiple versions in each language. Automating it may be much easier to do this as part of the release process.

The Argo Server APIs in v2.5 are quite different to the K8S APIs in v2.4, and include new operations for archiving API and for downloading artifacts that did not exist before. This is what it looks like: argoproj/argo-workflows#2036

However - perhaps I was hasty in generating the APIs - and for that I apologize. To footnote this, I did also generate a Java SDK: https://github.com/argoproj-labs/argo-workflow-java-sdk

I'm acutely aware that Python is not my strong point - nor am I an end user. So I'm not the best person to do this.

I know you have some questions about the labs, so I've asked a colleague who is more closely involved to reach out to you.

I do hope we can work together on this.

Alex

from argo-python-dsl.

Hey @alexec and thank you for the clarification and no need to apologise as I responded quite hastily as well. @ed Lee has already clarified a bit about @argoproj-labs as well, so if that is the colleague you're referring to, thank you for forwarding him to me as well.

If the ability to generalize the code generation is the case here, then I believe this approach is completely justifiable and makes sense. With my argo client I wanted to stay as close to the kubernetes-client as possible. It pulls the Argo Swagger spec so I imagine it shouldn't be hard to just update it to Argo 2.5 (hopefully) ... I was on sickness leave for about two weeks so I have a lot to catch up (including the awesome CronWorkflows I saw a the Argo community meeting) ... I'll take a better look at the Argo Server API and see how that fits my current approach with the existing argo-client I have, if it doesn't, I will consider migrating the SDK to your generated client. I'll also TAL at the argoproj's argo-python-sdk and see if/how I can contribute.

So, if we are about to migrate the Python SDK to argoproj-labs, it would perhaps be a good idea to consider I renamed it (because it is already confusing to me :) ), wdyt? If from your perspective the SDK is basically the generated models (agreed), than what I have is basically a DSL, right?

So how about I renamed the argo-python-sdk to argo-python-dsl and we can then TAL at the migration process together and move it under arogproj-labs. I am slowly approaching 0.1 so it should be quite stable pretty soon.

Does that sound good to you?

Cheers,
M

from argo-python-dsl.

@alexec Took a look at the SDK you generated under argoproj-labs and I think i got the point there, it is not meant to abstract the Kubernetes API, its purpose is to interact with the server directly as opposed to the https://github.com/CermakM/argo-client-python and hence serves a different (yet similar) use case.

I reference that in CermakM/argo-client-python#9.

FWIW: I just generated new models and paths in CermakM/argo-client-python#14, so far so good. Haven't got to the testing yet, tho.

from argo-python-dsl.

Hosted at https://github.com/argoproj-labs/argo-python-dsl

from argo-python-dsl.