It's true that the one character ^-flags are a little non-obvious. I think the main issue is that the opening carats are used both for the ^-flags and the optional name of the command. If tup were to simply move to ^-directives, how would you propose to parse multiple directives? Currently ^oc^ is distinct from ^o chroot^. But if carats were directives, it seems less obvious.
Two simple options are: 1. You could put some special delimiter like ^output,chroot^ does both directives, and ^output chroot^ does output detection of a command named chroot, but that seems potentially more obtuse (although admittedly maybe only in this highly contrived example). 2. You could view the optional name as another directive (like rename) that takes one argument, so maybe it would be ^output chroot^ versus ^output rename chroot^ but any kind of change where tup has directives that take different numbers of arguments will add some complexity to the ^-directive parser. Neither of these seem great. There's probably some better solution that I'm not thinking of. However, this change seems like something to be scheduled for 0.8, while adding the ^b flag could be harmlessly pushed to 0.7.X. On Tuesday, December 22, 2015 at 6:29:08 PM UTC-5, Pat Pannuto wrote: > > As a small usability thought, perhaps it would be better to change the > semantics from carat _flags_ to carat _directives_. Specifically, I'm > thinking the syntax should be something more like ^chroot (replacing > ^c) and ^bash. > > The one-character %-flags in tup rules are a little more standard and > align with natural idioms for a build system, easy to recall or > intuit. That's less true with the ^-flags as they change underlying > mechanics in a way that may be non-obvious. > > On 12/22/15, Erik <[email protected] <javascript:>> wrote: > > > > > > On Wednesday, December 16, 2015 at 2:21:01 PM UTC-5, [email protected] > > wrote: > >> > >> On Fri, Dec 11, 2015 at 2:31 PM, Erik <[email protected] > <javascript:>> > >> > >> wrote: > >> > >>> I probably use Tup a little differently than most people. Instead of > >>> using it to build software (which I do sometimes), I use it for > repeated > >>> > >>> data analysis and graph generation. One my tup rules looks something > >>> like > >>> > >>> : input.json |> < %f simulator | jq -f extract_something.jq > %o |> > >>> output.json > >>> > >>> where the simulator produces a lot of output, but in this case I only > >>> care about one aspect. Without pipefail, the simulator might fail, jq > >>> will > >>> get empty input, which it's fine with, and the result is an empty > output > >>> > >>> file. This then causes the next rule that uses output.json to fail, > >>> because > >>> it's empty, but the problem was the previous rule. > >>> > >> > >> Another option here is to move the command bits into a bash script, and > >> execute that in the rule: > >> > >> foo.bash: > >> #! /bin/bash -e -o pipefail (does this work?) > >> $1 simulator | jq -f ... > >> > >> Tupfile: > >> : input.json |> ./foo.bash %f > %o |> output.json > >> > >> That's not ideal if the majority of your commands are pipelines though, > of > >> > >> course. > >> > > > > As Ben said, you can't do this per say, but you could have a bash script > > and make the first line 'set -e -o pipefail'. This does work, but almost > > equally as annoying as the other solutions. > > > > > >> > >> > >>> > >>> In general, I find it hard to believe that (especially with tup), > there's > >>> > >>> ever a time when you wouldn't want pipefail to be active, but maybe > I'm > >>> unique in that feeling. > >>> > >> > >> I'm inclined to agree, and if /bin/sh supported pipefail I'd definitely > >> consider turning it on. Maybe it does and I haven't found where that is > in > >> > >> the manual? > >> > >> I'm hesitant to change the shell wholesale to bash though - even though > I > >> > >> use it everyday, I'm not sure if there are places where it isn't > installed > >> > >> by default. > >> > > > > As far as I can tell, sh has not pipefail options, and my search for > > workarounds online have yielded nothing satisfactory. I think I > generally > > agree that it would be potentially problematic if tup switched to bash. > I > > don't know of any places where it's not included, but it seems likely > that > > the small gain isn't worth removing tup from users who don't have bash > > installed. > > > > > >> > >> > >>> > >>> > >>> I like your suggestion about the ^p^ flag, although it seems a little > >>> strange that a flag would also change execution to bash. However, it > >>> feels > >>> like a reasonable way to accomplish this without requiring pipefail to > be > >>> > >>> active for all :-rules. After looking at the code though, another > option > >>> > >>> that seems easy would be to have a tup config option that specifies > the > >>> command that executes all of :-rules. This may be somewhat frowned > upon > >>> due > >>> to "changing any of these options should not affect the end result of > a > >>> successful build" (*), but having the default: > >>> > >>> updater.command = /bin/sh -e -c > >>> > >>> be there, but have the ability to change it to > >>> > >>> updater.command = /bin/bash -e -o pipefail -c > >>> > >>> would be very convenient, and would provide a lot of flexibility with > how > >>> > >>> tup is run. E.g. a user could just specify bash to get access to the > more > >>> > >>> advanced bash syntax. The downside is that it has the potential to > >>> violate > >>> the rules (*) of a tup config as stated above. An potentially absurd > >>> example would be setting > >>> > >>> update.command = /usr/bin/env python -c > >>> > >> > >> I think if we did something like this, we would need to specify it in > the > >> > >> :-rule somehow rather than in the options. For example, if one of the > >> rules > >> requires bash (or other shell) for something, you wouldn't want to > require > >> > >> every user of the software to overwrite their options file with the > >> correct > >> update.command setting. > >> > >> Potentially we could add this more easily in the lua parser, with > >> something like: > >> > >> tup.definerule{command='false | echo foo', shell='/bin/bash -e -o > pipefail > >> > >> -c'} > >> > >> I'm not sure what it would look like in the regular Tupfile parser > without > >> > >> something like the ^-flag suggestion, which is less flexible. > >> > > > > I can get behind a ^-flag that changes the shell. Potentially just ^b > for > > bash with pipefail. It seems like the fact that the command is executing > in > > > > bash not sh is more relevant than pipefail, which seems like a safe > default > > > > for tup if it were executing commands in bash. Pending any other > comments, > > I'll look into adding a flag that does this (using /usr/bin/env bash). > If > > that works, I'll look into adding a shell option to the lua parser. > > > > > >> > >> > >>> > >>> I'm curious about everyone's thoughts about this. I have my hacky > >>> solution, which means I'm fine for the time being, but I'd be up for > >>> submitting a pull request of a more reasonable implementation of one > of > >>> these ideas if it seemed worthwhile. > >>> > >>> > >> I'm curious if others have thoughts here too :) > >> > >> Thanks, > >> -Mike > >> > > > > -- > > -- > > tup-users mailing list > > email: [email protected] <javascript:> > > unsubscribe: [email protected] <javascript:> > > options: http://groups.google.com/group/tup-users?hl=en > > --- > > You received this message because you are subscribed to the Google > Groups > > "tup-users" group. > > To unsubscribe from this group and stop receiving emails from it, send > an > > email to [email protected] <javascript:>. > > For more options, visit https://groups.google.com/d/optout. > > > -- -- tup-users mailing list email: [email protected] unsubscribe: [email protected] options: http://groups.google.com/group/tup-users?hl=en --- You received this message because you are subscribed to the Google Groups "tup-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
