Commit Graph

16 Commits

Author SHA1 Message Date
1b9b8cc886
Set test formatter to progress 2016-05-29 17:32:22 +02:00
395621b27a
Fix tests for sdist
We now create the necessary directories and files
for the tests on-the-fly.
2016-05-29 17:29:13 +02:00
86a4b9ade2
Add IO modules, previously from HSFM 2016-05-09 16:53:31 +02:00
7e8c745e35
Clean up, rewrite stuff 2016-04-16 18:17:44 +02:00
d15e4b8ad9 Fork chrisdone's path library
I wasn't happy with the way it dealt with Dir vs File things. In his
version of the library, a `Path b Dir` always ends with a trailing
path separator and `Path b File` never ends with a trailing path separator.

IMO, it is nonsensical to make a Dir vs File distinction on path level,
although it first seems nice.
Some of the reasons are:
* a path is just that: a path. It is completely disconnected from IO level
  and even if a `Dir`/`File` type theoretically allows us to say "this path
  ought to point to a file", there is literally zero guarantee that it will
  hold true at runtime. So this basically gives a false feeling of a
  type-safe file distinction.
* it's imprecise about Dir vs File distinction, which makes it even worse,
  because a directory is also a file (just not a regular file). Add symlinks
  to that and the confusion is complete.
* it makes the API oddly complicated for use cases where we basically don't
  care (yet) whether something turns out to be a directory or not

Still, it comes also with a few perks:
* it simplifies some functions, because they now have guarantees whether a
  path ends in a trailing path separator or not
* it may be safer for interaction with other library functions, which behave
  differently depending on a trailing path separator (like probably shelly)

Not limited to, but also in order to fix my remarks without breaking any
benefits, I did:
* rename the `Dir`/`File` types to `TPS`/`NoTPS`, so it's clear we are only
  giving information about trailing path separators and not actual file
  types we don't know about yet
* add a `MaybeTPS` type, which does not mess with trailing path separators
  and also gives no guarantees about them... then added `toNoTPS` and
  `toTPS` to allow type-safe conversion
* make some functions accept more general types, so we don't unnecessarily
  force paths with trailing separators for `(</>)` for example... instead
  these functions now examine the paths to still have correct behavior.
  This is really minor overhead. You might say now "but then I can append
  filepath to filepath". Well, as I said... we don't know whether it's a
  "filepath" at all.
* merge `filename` and `dirname` into `basename` and make `parent` be
  `dirname`, so the function names match the name of the POSIX ones,
  which do (almost) the same...
* fix a bug in `basename` (formerly `dirname`) which broke the type
  guarantees
* add a pattern synonym for easier pattern matching without exporting
  the internal Path constructor
2016-03-08 22:53:42 +01:00
Chris Done
62c681819c Update test suite 2016-03-04 15:09:21 +01:00
Chris Done
04608e0e53 Reject only .. and . (#13) 2016-03-04 15:06:27 +01:00
Chris Done
2e109c86d8 Reject path consisting of all "." (fixes #13)
Ping @mrkkrp
2016-03-04 14:39:17 +01:00
Magnus Therning
b5cff315a1 Clarify what limitations the RelX parsers have.
Signed-off-by: Magnus Therning <magnus@therning.org>
2016-01-07 16:15:06 +01:00
Ethan Glasser-Camp
a4ed4cd504 test: missing case for parseRelFile 2015-07-08 20:28:15 -04:00
Chris Done
4e1816392a Fix stripDir p p /= Nothing bug 2015-05-27 17:08:03 +02:00
Chris Done
87a56a93b8 Disallow .. 2015-05-22 11:35:52 +02:00
Chris Done
a68b46b060 Update test suite 2015-05-11 19:01:35 +02:00
Chris Done
ef8503f38f Rename parentAbs to parent 2015-05-11 18:40:54 +02:00
Chris Done
c4895949ee Add some operations 2015-05-08 14:03:37 +02:00
Chris Done
1e5b6675c2 Basic Path type with parsers and test suite 2015-05-08 13:14:54 +02:00