[opensuse-buildservice] [RFC] Changed osc ls behavior in project/package dir
Hi all, I'm not satisfied with a behavior of osc ls in project/package dir - instead of listing of a project list on a server, I expect it will list a content of a current project/package instead. So I wrote patch changing it. Simple example: user@host:~/Base\:System/ed> osc ls _link ed-1.4.tar.gz ed.changes ed.spec ready There is one problem prevents me to push this commit - with this patch is impossible to list a content of an another project/package inside this directory. The root of the problem comes from a current command syntax, which I considered weird - let see how it looks osc ls [PROJECT [PACKAGE [FILE]]]] osc ls -b [PROJECT [PACKAGE [REPOSITORY [ARCH]]]] The first thing I don't understand is a FILE argument - don't see a reason why it's necessary. The test of existence of a file in repository is straightforward osc ls PRJ PKG | grep file # in shell file in meta_get_filelist(...) # in python ... and this syntax don't allow to test more than one file per call, which is not really useful. The second problem is with REPOSITORY and ARCH arguments in binary listing - it produces a some of mess in code, because it's duplicated by -r/-a options. And those two positional but optional arguments produces an ambiguity while parsing a command line - what's the expected result of user@host:package> osc ls ARG1 user expects the osc ls PROJECT or osc ls FILE? user@host:package> osc ls -b ARG1 ARG2 In this case what user wants? osc ls -b PROJECT PACKAGE, or osc ls -b REPOSITORY ARCH? My proposal and solution is to use the second option, which disallows the listing of an another project/package inside project/package dir, but it should be more convenient. Comments are welcome Michal Vyskocil
Michal Vyskocil wrote:
There is one problem prevents me to push this commit - with this patch is impossible to list a content of an another project/package inside this directory.
We could introduce 'osc rls'
The root of the problem comes from a current command syntax, which I considered weird - let see how it looks
osc ls [PROJECT [PACKAGE [FILE]]]] osc ls -b [PROJECT [PACKAGE [REPOSITORY [ARCH]]]]
The first thing I don't understand is a FILE argument - don't see a reason why it's necessary. The test of existence of a file in repository is straightforward
No idea either.
The second problem is with REPOSITORY and ARCH arguments in binary listing - it produces a some of mess in code, because it's duplicated by -r/-a options.
I've added those arguments as the -r and -a options are just annoying and don't work with c&p. They are left for backwards compatibility.
And those two positional but optional arguments produces an ambiguity while parsing a command line - what's the expected result of
user@host:package> osc ls ARG1
user expects the osc ls PROJECT or osc ls FILE?
user@host:package> osc ls -b ARG1 ARG2
In this case what user wants? osc ls -b PROJECT PACKAGE, or osc ls -b REPOSITORY ARCH?
That kind of ambiguity hits osc all over the place which is both a bug and a feature IMHO. Ambiguity sometimes allows osc to do something smart (or stupid ;-). Jürgen once suggested to use '.' when referring to the current project/package.
My proposal and solution is to use the second option, which disallows the listing of an another project/package inside project/package dir, but it should be more convenient.
I'd agree and for explicitly referring to another project one could use 'rls'. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-buildservice+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-buildservice+help@opensuse.org
participants (2)
-
Ludwig Nussel -
Michal Vyskocil