Commit Graph

38 Commits

Author SHA1 Message Date
5b08e14b55
Add createDirRecursive, fixes #6 2016-06-13 01:28:55 +02:00
a5942ff026
Use IfElse package for whenM/unlessM 2016-06-05 21:52:52 +02:00
4d71ad08ce
Release 0.8.0 2016-06-05 17:56:31 +02:00
ed06543981
Proper GHC conditionals to fix compiler warnings 2016-06-05 16:16:41 +02:00
64ae6db83a
New API: use CopyMode for overwriting and introduce RecursiveMode
This allows to specify the behavior on recursive operations,
such that one can collect failures instead of dying on the first
failure.
2016-06-05 03:13:33 +02:00
2a0a88a96d
Release 0.7.5 2016-06-04 00:39:03 +02:00
69dbf6714d
Relicense to BSD3 2016-06-04 00:39:03 +02:00
641e23c3ef
Release 0.7.3 2016-05-30 17:16:37 +02:00
d15d7761c1
Don't expose HPath.Internal 2016-05-30 13:01:47 +02:00
7e924d3386
Remove benchmarks
We don't really need this.
2016-05-29 22:45:26 +02:00
b603f72407
Release 0.7.2 2016-05-29 17:47:22 +02:00
98ca6c5d86
Sort module list alphabetically 2016-05-29 17:44:00 +02:00
8d948366f9
Add hspec for createSymlink 2016-05-29 17:43:43 +02:00
86e7496917
Re-add missing spec modules so they show up in sdist 2016-05-29 17:38:27 +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
08fa277b31
Release 0.7.1 2016-05-24 15:36:34 +02:00
7fa4c041a9
Remove -Wno-redundant-constraints since it's only in ghc >= 8.0.1 2016-05-24 03:31:01 +02:00
f2fe5a3419
Hide wrong -Wredundant-constraints messages 2016-05-24 03:26:07 +02:00
b55cf6d9f3
Fix for bytestring versions less than 0.10.8 2016-05-24 03:26:01 +02:00
ae9a806c2e
Fix to latest sendfile version to simplify imports 2016-05-24 03:13:36 +02:00
eb72fce33f
Add splitSearchPath, getSearchPath and stripExtension 2016-05-24 02:07:04 +02:00
a8ccfc2587
Release 0.7.0 2016-05-18 14:02:08 +02:00
797dcaf725
Backport changes from posix-paths PR:
* add isFileName
* add hasParentDir
* add hiddenFile
* add our own openFd version for more control
* small documentation improvements
* add a getDirectoryContents' version that works on Fd
* fix linting warnings
* lift version constraints in benchmark

Also adjust HPath.IO to work with the new API.
2016-05-18 04:11:40 +02:00
0fa66cd581
Use sendfile for copying and read/write as fallback 2016-05-18 03:47:39 +02:00
456af3b1ab
Release 0.6.0 2016-05-10 00:45:40 +02:00
7aac9bcb93
Adjust description 2016-05-09 19:06:31 +02:00
010756e190
Fix cabal file 2016-05-09 18:03:27 +02:00
9a4fd00710
Release 0.5.9 2016-05-09 17:37:33 +02:00
86a4b9ade2
Add IO modules, previously from HSFM 2016-05-09 16:53:31 +02:00
6638cd8cc1
Create HPath.IO module, adding canonicalizePath again 2016-05-09 14:40:30 +02:00
a946387330
Merge posix-paths into hpath 2016-05-09 13:31:20 +02:00
7e8c745e35
Clean up, rewrite stuff 2016-04-16 18:17:44 +02:00
148eeb619f
Implement String -> ByteString and vice versa conversion for filepaths 2016-04-05 00:55:25 +02:00
8c1bd139c0
Readd TH constructors 2016-04-05 00:54:36 +02:00
bd71947b2a
Use word8 package 2016-04-04 18:46:25 +02:00
491efe44a3
Use ByteString for paths instead of String 2016-04-04 17:29:35 +02:00
3c3a2d2766
Switch to new layout 2016-03-30 02:47:42 +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