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]> 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] > 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. > -- -- 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.
