I am giving a talk about Software Collections to my colleagues at work on Monday and I remembered the confusion I first had with the scl command. I was expecting the "scl enable" command to set up symbolic links or something - i.e. make some long-lasting change to the envionment in the way that perlbrew does, i.e. set up or enable a particular version of software. The word "enable" here is actually a misnomer, and scl is more akin to the coreutils "modified command invocation" commands (chroot, env, nice, nohup, etc.) - or even ssh. The other thing I trip over is that all arguments up to the last are collection names.
I know that the scl command is pretty much established now, but a nicer syntax would be:
scl-env --with perl-5.18 perl script argument ...
i.e. provide the collection name as an option and let the rest of the command line be passed to the command to be invoked with the modified environment. If you want to run a command with multiple collections enabled then give the --with option multiple times, or provide the names in a single argument separated with spaces or commas, e.g.
scl-env --with perl-5.18 --with mysql-5.1 perl script argument ...
or
scl-env --with perl-5.18,mysql-5.1 perl script argument ...
Just my two cents' worth.
Andrew
On 01/19/2013 07:40 PM, Andrew Ford wrote:
I am giving a talk about Software Collections to my colleagues at work on Monday and I remembered the confusion I first had with the scl command. I was expecting the "scl enable" command to set up symbolic links or something - i.e. make some long-lasting change to the envionment in the way that perlbrew does, i.e. set up or enable a particular version of software. The word "enable" here is actually a misnomer, and scl is more akin to the coreutils "modified command invocation" commands (chroot, env, nice, nohup, etc.) - or even ssh. The other thing I trip over is that all arguments up to the last are collection names.
I know that the scl command is pretty much established now, but a nicer syntax would be:
scl-env --with perl-5.18 perl script argument ...
i.e. provide the collection name as an option and let the rest of the command line be passed to the command to be invoked with the modified environment. If you want to run a command with multiple collections enabled then give the --with option multiple times, or provide the names in a single argument separated with spaces or commas, e.g.
scl-env --with perl-5.18 --with mysql-5.1 perl script argument ...
or
scl-env --with perl-5.18,mysql-5.1 perl script argument ...
Just my two cents' worth.
Andrew
CC Jindrich for opinions. Some improvement of scl-utils would be nice. I also would like to see behaviour similar to perlbrew. Anyway such changes wouldn't be good for stable release in EL releases.
Marcela
Dne 19.1.2013 19:40, Andrew Ford napsal(a):
I am giving a talk about Software Collections to my colleagues at work on Monday and I remembered the confusion I first had with the scl command. I was expecting the "scl enable" command to set up symbolic links or something - i.e. make some long-lasting change to the envionment in the way that perlbrew does, i.e. set up or enable a particular version of software. The word "enable" here is actually a misnomer, and scl is more akin to the coreutils "modified command invocation" commands (chroot, env, nice, nohup, etc.) - or even ssh. The other thing I trip over is that all arguments up to the last are collection names.
I might be mistaken, but the "enable" is the name of the scriptlet you are executing. It is totally up to you, how you will name it. Or at least that was original idea. The "enable" is just convention.
I know that the scl command is pretty much established now, but a nicer syntax would be:
scl-env --with perl-5.18 perl script argument ...i.e. provide the collection name as an option and let the rest of the command line be passed to the command to be invoked with the modified environment. If you want to run a command with multiple collections enabled then give the --with option multiple times, or provide the names in a single argument separated with spaces or commas, e.g.
scl-env --with perl-5.18 --with mysql-5.1 perl script argument ...or
scl-env --with perl-5.18,mysql-5.1 perl script argument ...Just my two cents' worth.
However, not sure if naming the scriptlet "--with" is good idea ;) But the best part is that it works :D (I renamed existing scriplet, not sure if it works in every place of the build chain though).
Vít
Vít Ondruch wrote:
Dne 19.1.2013 19:40, Andrew Ford napsal(a):
I am giving a talk about Software Collections to my colleagues at work on Monday and I remembered the confusion I first had with the scl command. I was expecting the "scl enable" command to set up symbolic links or something - i.e. make some long-lasting change to the envionment in the way that perlbrew does, i.e. set up or enable a particular version of software. The word "enable" here is actually a misnomer, and scl is more akin to the coreutils "modified command invocation" commands (chroot, env, nice, nohup, etc.) - or even ssh. The other thing I trip over is that all arguments up to the last are collection names.
I might be mistaken, but the "enable" is the name of the scriptlet you are executing. It is totally up to you, how you will name it. Or at least that was original idea. The "enable" is just convention.
I know that the scl command is pretty much established now, but a nicer syntax would be:
scl-env --with perl-5.18 perl script argument ...i.e. provide the collection name as an option and let the rest of the command line be passed to the command to be invoked with the modified environment. If you want to run a command with multiple collections enabled then give the --with option multiple times, or provide the names in a single argument separated with spaces or commas, e.g.
scl-env --with perl-5.18 --with mysql-5.1 perl script argument ...or
scl-env --with perl-5.18,mysql-5.1 perl script argument ...Just my two cents' worth.
However, not sure if naming the scriptlet "--with" is good idea ;) But the best part is that it works :D (I renamed existing scriplet, not sure if it works in every place of the build chain though).
One of my points was that it is annoying to have to quote the command that you want to execute to make it a single argument to scl. I would imagine that the most common use case would be to use a single collection, so if you wanted to run with multiple collections it would be better to have to quote the collection list as a single first argument. That would make it more like sudo, nice, nohup, etc. In fact if an enabling command made a note of the collection specified - in a user configuration file or it could be set with an environment variable, then one could omit the collection on each call to scl (or whatever the command to run a command in a collection was - I realize that one cannot change published functionality), so perhaps:
export SCL_COLLECTIONS=perl516 scl-run perl script.pl argument ...
Such a syntax seems a lot less cluttered to me - and if one wanted to use a different collection but with the collection environment variable unchanged:
export SCL_COLLECTIONS=perl516 scl-run --with perl518 perl script.pl argument ...
(the option name wouldn't have to be --with - I just couldn't think of a better name when I was writing the first email).
Andrew
softwarecollections@lists.fedorahosted.org