expected_output.css is not generated (neither with -g nor --nuke)

[mgreter]

It is only updated once it exists - it should be created if requested

[chriseppstein]

I can't reproduce this.

➜  sass-spec git:(master) ls spec/basic/foo/
input.scss
➜  sass-spec git:(master) bundle exec sass-spec.rb  -g spec/basic/foo/
Recursively searching under /Users/ceppstei/Projects/sass-spec/spec/basic/foo for test files to test 'sass' against language version 3.4.
3.4.21 (Selective Steve)
Run options: --seed 1647

# Running:

.

Finished in 0.182096s, 5.4916 runs/s, 5.4916 assertions/s.

1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
➜  sass-spec git:(master) ls spec/basic/foo/
expected_output.css input.scss

[mgreter]

Will give it another try later, brace yourself to be flooded by PRs ;)

[chriseppstein]

@mgreter uh. yeah, I had been restructuring the directories somewhat, but I will abort that and wait until you're done.

[mgreter]

Well I just create tests in libsass-open-issues, should not get any merge conflicts ...

[saper]

-g needs an argument:

m> rm -rf spec/basic/foo
m> mkdir spec/basic/foo
m> echo 'div { color: white; } ' > spec/basic/foo/input.scss
m> ruby \
    -I /home/saper/sw/sass/lib \
    /home/saper/sw/libsass/sass-spec/sass-spec.rb \
    -c /home/saper/sw/sass/bin/sass \
    -g nested spec/basic/foo
Recursively searching under directory 'spec/basic/foo' for test files to test '/home/saper/sw/sass/bin/sass' with.
Sass 3.4.14.2e0f33b (Selective Steve)
Run options: --seed 57991

# Running:

.

Finished in 0.411813s, 2.4283 runs/s, 12.1414 assertions/s.

1 runs, 5 assertions, 0 failures, 0 errors, 0 skips
m> find spec/basic/foo
spec/basic/foo
spec/basic/foo/input.scss
spec/basic/foo/expected_output.css
m> cat spec/basic/foo/expected_output.css
div {
  color: white; }

[chriseppstein]

-g doesn't take an argument and is functionally equivalent to nuke at this point based on my reading of the code. was it the intent that -g and --nuke behave differently?

[saper]

I have introduced it in #509 and it always has had an argument... (unless I have heavily misunderstood something).

My problem with --nuke is that it only re-generates existing output formats. It does not know how to create new ones or create the test from scratch (when having only input.scss in the directory).

--generate all could have superseded --nuke but --nuke has a useful test case - just regenerate the results for the existing output formats, maybe --nuke could be named --generate existing.

I needed -g after #494 to test for error cases - it makes no sense to test for 4 output formats if the only expected result for all of them is the error message.
Also many test cases don't need all 4 output formats (I know there is a discussion somewhere else to get rid of them completely). For me -g format is a gentle way to move into this direction.

[chriseppstein]

@saper There's only one output format per test case now, so after my recent work, it seems that the two options have degenerated into being the same.

[saper]

Didn't know that. In that case -g is now something different :)

Yes, the current code has conflated them completely. Previously you couldn't --nuke to create new output files from scratch.

So I think it's time to drop one of them I guess!

[chriseppstein]

@saper ok. I've dropped --nuke in favor of -g or --generate