FilePath modification proposal
Hi, As maintainer, it's kind of a grey area if I need to make proposals for the filepath library, but since I'm a relatively new active maintainer for a Core library, I thought I'd err on the side of caution. Please yell if you think these are a bad idea, otherwise I'll just do them (probably over the next few weeks). * Change 1: Add -<.> as an alias for replaceExtension with the same precedence as <.> This change has been in Shake for a while now, and seems generally useful. It isn't an operator in the lens library, and it reads nicely as a combination of - (remove something) and <.> (addExtension). The argument order of replaceExtension is a bit unfortunately, since replace functions usually have the thing to replace with first, but since extensions are at the end of the FilePaths that suggests making it the second argument (which is what filepath does). In contrast, -<.> has a very obvious argument order. * Change 2: Stop testing as part of GHC The test suite is complicated enough, since it generates code from the doc comments. Having the test suite also run by GHC complicates things further, since it has to integrate with the GHC test suite environment with extra Makefiles etc. Since August 2011 the FilePath test suite actually passes even if you break the properties (oops!) so it's provided no value at all in the last 3 years. In general, running all the tests in all the places is a good thing. But I think filepath is a bit different given it's exclusively cross-platform string manipulations, so I don't think its runtime behaviour is version/platform sensitive in any way. I also develop on Windows with 4 versions of GHC, and Travis tests it on Linux with 6 versions of GHC. That seems sufficient test coverage. * Change 3: Check in the generated test code If you check out the filepath repo it won't build - you have to run some code to generate the tests first. That's a barrier to entry, and makes testing with GHC harder. I'm increasingly starting to believe that for a small number of small files where the generator ships with the code, it's easier to check in the generated code and then have Travis run the generator and check nothing changes. It's easier to get started, easier to debug when things change, and the only real cost is a few extra checkins. Thanks, Neil
hi, have no vote in the committee, but re
* Change 1: Add -<.> as an alias for replaceExtension with the same precedence as <.>
i am very much in favor. i have (locally) defined that or a similar alias a few times already. the other changes are imo your choice alone, as you are the (only?) person maintaining it. (i prefer not checking in auto-generated files, but... whatever.) thank you, neill, for maintaining filepath, tobias florek
I personally think that checking in any non-platform dependent file is
usually a best practice. Not requiring the generator to be run when
initially checking out the code might seem unsafe, but seeing the generated
code in the diff communicates that you properly ran the generator on your
local system (not just the first time checking out, but every time).
On Sun, Oct 19, 2014 at 5:53 AM, Tobias Florek
hi,
have no vote in the committee, but re
* Change 1: Add -<.> as an alias for replaceExtension with the same
precedence as <.>
i am very much in favor. i have (locally) defined that or a similar alias a few times already.
the other changes are imo your choice alone, as you are the (only?) person maintaining it. (i prefer not checking in auto-generated files, but... whatever.)
thank you, neill, for maintaining filepath, tobias florek
_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries
On 2014-10-19 at 14:35:02 +0200, Neil Mitchell wrote: [...]
* Change 3: Check in the generated test code
Can't something in the style of https://hackage.haskell.org/package/doctest be used to avoid having to run a generator manually? Btw, Haddock has even markup support for QC properties via "prop>"-prefixed code-blocks. Cheers, hvr
Can't something in the style of
https://hackage.haskell.org/package/doctest
be used to avoid having to run a generator manually?
It would, but then instead of generating a file (pretty easy), I have to go through the GHC API (a lot more fiddly). Alternatively, I could just have the tester spit out a temporary .hs file and run over it in one go - which works, but means all the nice Cabal stuff for dependencies of the test suite get a bit lost and I have to assume a "good" GHC on the $PATH. Both avoid checking in generated code, but end up a bit more complex in other respects.
Btw, Haddock has even markup support for QC properties via "prop>"-prefixed code-blocks.
Yes, but here I want slightly lighter weight properties (I infer what is a variable and what isn't), and also multi-module properties (most properties are tested against both .Windows and .Posix paths). I almost always find I can get slightly cleaner tests by writing a generator myself, and that the effort writing the generator is minimal and reducing the difficulty of writing tests makes me write more of them. Thanks, Neil
participants (4)
-
Greg Weber -
Herbert Valerio Riedel -
Neil Mitchell -
Tobias Florek