I was thinking about the cli tool we want, now that we have the api in place to make it possible to submit from a cli.
to start with I was thinking of a simple tool that did a small number of basic commands:
create coprname -r distro -r distro -r distro -a arch -a arch --repo=somerepo --repo=somerepo -p pkgurl1 -p pkgurl2 -p pkgurl3 edit coprname (not sure what this would do yet) info coprname (dumps out info like the returned urls of builds, number of builds, etc) build coprname pkgurl1 pkgurl2 pkgurl3 delete coprname
What do you think? Too broad? not broad enough?
-sv
On 01/11/2013 10:47 AM, Seth Vidal wrote:
I was thinking about the cli tool we want, now that we have the api in place to make it possible to submit from a cli.
to start with I was thinking of a simple tool that did a small number of basic commands:
create coprname -r distro -r distro -r distro -a arch -a arch --repo=somerepo --repo=somerepo -p pkgurl1 -p pkgurl2 -p pkgurl3 edit coprname (not sure what this would do yet) info coprname (dumps out info like the returned urls of builds, number of builds, etc) build coprname pkgurl1 pkgurl2 pkgurl3 delete coprname
What do you think? Too broad? not broad enough?
-sv
That is everything I want, and more.
Troy
On Fri, 11 Jan 2013, Seth Vidal wrote:
I was thinking about the cli tool we want, now that we have the api in place to make it possible to submit from a cli.
to start with I was thinking of a simple tool that did a small number of basic commands:
create coprname -r distro -r distro -r distro -a arch -a arch --repo=somerepo --repo=somerepo -p pkgurl1 -p pkgurl2 -p pkgurl3 edit coprname (not sure what this would do yet) info coprname (dumps out info like the returned urls of builds, number of builds, etc) build coprname pkgurl1 pkgurl2 pkgurl3 delete coprname
What do you think? Too broad? not broad enough?
Expanding on this a bit - I suspect that info coprname would dump out a json blob with that info so it can be easily parsed.
I was trying to think of the workflow:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64 coprcli build mycopr pkg1 pkg2 pkg3 coprcli info mycopr | python -m json.tool | check for something_or_another
does that make sense?
-sv
On Fri, Jan 11, 2013 at 01:53:49PM -0500, Seth Vidal wrote:
On Fri, 11 Jan 2013, Seth Vidal wrote:
I was thinking about the cli tool we want, now that we have the api in place to make it possible to submit from a cli.
to start with I was thinking of a simple tool that did a small number of basic commands:
create coprname -r distro -r distro -r distro -a arch -a arch --repo=somerepo --repo=somerepo -p pkgurl1 -p pkgurl2 -p pkgurl3 edit coprname (not sure what this would do yet) info coprname (dumps out info like the returned urls of builds, number of builds, etc) build coprname pkgurl1 pkgurl2 pkgurl3 delete coprname
What do you think? Too broad? not broad enough?
That's awesome, I think its right on the money.
Expanding on this a bit - I suspect that info coprname would dump out a json blob with that info so it can be easily parsed.
I was trying to think of the workflow:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64 coprcli build mycopr pkg1 pkg2 pkg3 coprcli info mycopr | python -m json.tool | check for something_or_another
does that make sense?
Makes sense, this is great. Kudos! +1
-AdamM
----- Original Message -----
On Fri, 11 Jan 2013, Seth Vidal wrote:
I was thinking about the cli tool we want, now that we have the api in place to make it possible to submit from a cli.
to start with I was thinking of a simple tool that did a small number of basic commands:
create coprname -r distro -r distro -r distro -a arch -a arch --repo=somerepo --repo=somerepo -p pkgurl1 -p pkgurl2 -p pkgurl3 edit coprname (not sure what this would do yet) info coprname (dumps out info like the returned urls of builds, number of builds, etc) build coprname pkgurl1 pkgurl2 pkgurl3 delete coprname
What do you think? Too broad? not broad enough?
Expanding on this a bit - I suspect that info coprname would dump out a json blob with that info so it can be easily parsed.
I was trying to think of the workflow:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64 coprcli build mycopr pkg1 pkg2 pkg3 coprcli info mycopr | python -m json.tool | check for something_or_another
does that make sense?
-sv
It's on my TODO list to do a cli client. It will require some new views (or perhaps just altering the current views) and the cli client itself. Since I finished the most pressing stuff last week, I'll get on it ASAP.
On Mon, 14 Jan 2013, Bohuslav Kabrda wrote:
What do you think? Too broad? not broad enough?
Expanding on this a bit - I suspect that info coprname would dump out a json blob with that info so it can be easily parsed.
I was trying to think of the workflow:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64 coprcli build mycopr pkg1 pkg2 pkg3 coprcli info mycopr | python -m json.tool | check for something_or_another
does that make sense?
-sv
It's on my TODO list to do a cli client. It will require some new views (or perhaps just altering the current views) and the cli client itself. Since I finished the most pressing stuff last week, I'll get on it ASAP.
Slavek, which part is on your todo list? I was playing with cli tool itself - just option/arg/env parsing and general layout. If you want to focus on the views necessary to make the tool work first that might be a good place to start? If you'd rather work on the cli-piece first just let me know.
Thanks, -sv
----- Original Message -----
On Mon, 14 Jan 2013, Bohuslav Kabrda wrote:
What do you think? Too broad? not broad enough?
Expanding on this a bit - I suspect that info coprname would dump out a json blob with that info so it can be easily parsed.
I was trying to think of the workflow:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64 coprcli build mycopr pkg1 pkg2 pkg3 coprcli info mycopr | python -m json.tool | check for something_or_another
does that make sense?
-sv
It's on my TODO list to do a cli client. It will require some new views (or perhaps just altering the current views) and the cli client itself. Since I finished the most pressing stuff last week, I'll get on it ASAP.
Slavek, which part is on your todo list? I was playing with cli tool itself
just option/arg/env parsing and general layout. If you want to focus on the views necessary to make the tool work first that might be a good place to start? If you'd rather work on the cli-piece first just let me know.
Thanks, -sv
Hey Seth, I'd like to start with the views, so how about I create a document describing the API and then we'll implement our parts? So the cli is all yours, if you want to take it :) (I'm currently working on other functionality, but I suppose I could have something by the end of the week.)
Slavek.
On Tue, 15 Jan 2013, Bohuslav Kabrda wrote:
Hey Seth, I'd like to start with the views, so how about I create a document describing the API and then we'll implement our parts? So the cli is all yours, if you want to take it :) (I'm currently working on other functionality, but I suppose I could have something by the end of the week.)
Slavek, I am leaving for fudcon on thursday so I won't have too much time but I'll work on it after I work on the talks.
I'm going to try to recruit more people to work on coprs at fudcon. :)
-sv
On Tue, Jan 15, 2013 at 10:12:13AM -0500, Seth Vidal wrote:
I'm going to try to recruit more people to work on coprs at fudcon. :)
Hi,
I have had a little time to play with copr and tried to start working on the CLI. I am at the point that I think we will not be able to write down a CLI with the actual structure.
We are using web forms which are csrf protected and the goal of csrf is pretty much to ensure that a user is following a given path which is what we want to circumvent with the CLI.
So I am proposing that we build a /api/ which would expose the different possibilities that we described: - list the coprs of a user - create a new copr - build a copr - ...
I'll see if I get the time and courage to work on this in the airplane tomorrow, if I do, I'll send the patch here for review rather than pushing directly.
Pierre
----- Original Message -----
On Tue, Jan 15, 2013 at 10:12:13AM -0500, Seth Vidal wrote:
I'm going to try to recruit more people to work on coprs at fudcon. :)
Hi,
I have had a little time to play with copr and tried to start working on the CLI. I am at the point that I think we will not be able to write down a CLI with the actual structure.
We are using web forms which are csrf protected and the goal of csrf is pretty much to ensure that a user is following a given path which is what we want to circumvent with the CLI.
So I am proposing that we build a /api/ which would expose the different possibilities that we described:
- list the coprs of a user
- create a new copr
- build a copr
- ...
Yep, that was my idea. I never meant to use current views for both web and cli. That's why I created the "copr.logic" package that is aimed to provide the functionality common to both web and cli-api views. It's not optimal ATM, but I guess we will figure out the best approach when we actually start working on the cli-api. I was thinking of a simple REST cli-client + JSON answers from the server - or do you want to do it differently?
I'll see if I get the time and courage to work on this in the airplane tomorrow, if I do, I'll send the patch here for review rather than pushing directly.
Great, looking forward to it :)
Pierre _______________________________________________ copr-devel mailing list copr-devel@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/copr-devel
On Tue, Jan 22, 2013 at 01:27:25AM -0500, Bohuslav Kabrda wrote:
So I am proposing that we build a /api/ which would expose the different possibilities that we described:
- list the coprs of a user
- create a new copr
- build a copr
- ...
Yep, that was my idea. I never meant to use current views for both web and cli. That's why I created the "copr.logic" package that is aimed to provide the functionality common to both web and cli-api views. It's not optimal ATM, but I guess we will figure out the best approach when we actually start working on the cli-api. I was thinking of a simple REST cli-client + JSON answers from the server - or do you want to do it differently?
Great, we're on the same page then :)
Pierre
On Fri, Jan 11, 2013 at 01:53:49PM -0500, Seth Vidal wrote:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64
Ok so this is implemented API side and CLI side.
coprcli build mycopr pkg1 pkg2 pkg3
I just sent patches for this on the API side, I still have to do the CLI part but it should be pretty straight forward.
coprcli info mycopr | python -m json.tool | check for something_or_another
What's the idea behind this one? Returning raw json? Or just giving information about a copr (owner, chroots, packages (?), builds (I have no real idea of what we can/display))?
Thanks, Pierre
On Sat, 2013-02-02 at 17:58 +0100, Pierre-Yves Chibon wrote:
On Fri, Jan 11, 2013 at 01:53:49PM -0500, Seth Vidal wrote:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64
Ok so this is implemented API side and CLI side.
coprcli build mycopr pkg1 pkg2 pkg3
I just sent patches for this on the API side, I still have to do the CLI part but it should be pretty straight forward.
coprcli info mycopr | python -m json.tool | check for something_or_another
What's the idea behind this one? Returning raw json? Or just giving information about a copr (owner, chroots, packages (?), builds (I have no real idea of what we can/display))?
Seth?
BTW, I wanted to look at cliff because pkwat uses it and it seems pretty cool. Now that I have seen it, I have the feeling that it does not quite fit our use-case and it nicely adds a dependency and a layer of complexity when developing the application. If I rewrite the cli to a more common argparse based CLI, anything against?
Pierre
----- Original Message -----
On Sat, 2013-02-02 at 17:58 +0100, Pierre-Yves Chibon wrote:
On Fri, Jan 11, 2013 at 01:53:49PM -0500, Seth Vidal wrote:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64
Ok so this is implemented API side and CLI side.
coprcli build mycopr pkg1 pkg2 pkg3
I just sent patches for this on the API side, I still have to do the CLI part but it should be pretty straight forward.
coprcli info mycopr | python -m json.tool | check for something_or_another
What's the idea behind this one? Returning raw json? Or just giving information about a copr (owner, chroots, packages (?), builds (I have no real idea of what we can/display))?
Seth?
BTW, I wanted to look at cliff because pkwat uses it and it seems pretty cool. Now that I have seen it, I have the feeling that it does not quite fit our use-case and it nicely adds a dependency and a layer of complexity when developing the application. If I rewrite the cli to a more common argparse based CLI, anything against?
No problem on my side, use whatever suits you best.
Pierre
On Wed, 13 Feb 2013, Pierre-Yves Chibon wrote:
On Sat, 2013-02-02 at 17:58 +0100, Pierre-Yves Chibon wrote:
On Fri, Jan 11, 2013 at 01:53:49PM -0500, Seth Vidal wrote:
coprcli create mycopr -r epel-5 -r epel-6 -r fedora-18 -a i386 -a x86_64
Ok so this is implemented API side and CLI side.
coprcli build mycopr pkg1 pkg2 pkg3
I just sent patches for this on the API side, I still have to do the CLI part but it should be pretty straight forward.
coprcli info mycopr | python -m json.tool | check for something_or_another
What's the idea behind this one? Returning raw json? Or just giving information about a copr (owner, chroots, packages (?), builds (I have no real idea of what we can/display))?
Seth?
BTW, I wanted to look at cliff because pkwat uses it and it seems pretty cool. Now that I have seen it, I have the feeling that it does not quite fit our use-case and it nicely adds a dependency and a layer of complexity when developing the application. If I rewrite the cli to a more common argparse based CLI, anything against?
As long as it will run on rhel6 - I think it's fine. And if it only runs on rhel6 with something from epel - that's fine too.
I'm sorry for being AWOL for the last week or so. I've been completely covered up by the euca upgrade disaster.
For the future this is the only rule to follow with regard to waiting on a reply from me:
DO NOT BLOCK ON SETH.
If I complain about something you did following the above rule, refer me to that rule and I will grumble and then promptly shut up.
You are doing great work, do not wait for me to continue to do so.
-sv
Le vendredi 15 février 2013 à 15:18 -0500, Seth Vidal a écrit :
You are doing great work, do not wait for me to continue to do so.
I did not block on you, you did not block anything, but I can make sure to blame you for not working on this in the train where I was the last few hours if you like :)
No I was just wondering what you had in mind with this part, that you mentioned when you first spoke about the CLI tool:
coprcli info mycopr | python -m json.tool | check for
something_or_another
It is something like $ coprcli info foo Name: foo Description: bar ... last 5 builds: ...
Or did you have something else in mind (which I tend to think based on the succession of pipes you added) ?
Thanks :) Pierre
On Fri, 15 Feb 2013, Pierre-Yves Chibon wrote:
Le vendredi 15 février 2013 à 15:18 -0500, Seth Vidal a écrit :
You are doing great work, do not wait for me to continue to do so.
I did not block on you, you did not block anything, but I can make sure to blame you for not working on this in the train where I was the last few hours if you like :)
No I was just wondering what you had in mind with this part, that you mentioned when you first spoke about the CLI tool:
coprcli info mycopr | python -m json.tool | check for
something_or_another
It is something like $ coprcli info foo Name: foo Description: bar ... last 5 builds: ...
Or did you have something else in mind (which I tend to think based on the succession of pipes you added) ?
I'm fine with info outputting something trivially human readable.
I can just see what a user might end up doing with it.
<create copr> <submit build 1> <check build status in a loop using info and a series of horrible grep pipes :)> <submit build 2> <check build status in a loop using coprcli info> <get url of results from coprcli info> <use reposync to pull down all the pkgs to a local repo>
I guess I thought to make the json simple to access so we could keep people from using grep and ultimately making our life harder :)
-sv
copr-devel@lists.fedorahosted.org
-
Adam Miller -
Bohuslav Kabrda -
Pierre-Yves Chibon -
Seth Vidal -
Troy Dawson