path VS path-io

Compare path vs path-io and see what are their differences.

path

Typed filepath (by commercialhaskell)

path-io

Operations on files and directories with typed paths (by mrkkrp)
Our great sponsors
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • WorkOS - The modern identity platform for B2B SaaS
  • SaaSHub - Software Alternatives and Reviews
path path-io
3 0
119 30
0.0% -
4.8 5.6
5 months ago 4 days ago
Haskell Haskell
GNU General Public License v3.0 or later GNU General Public License v3.0 or later
The number of mentions indicates the total number of mentions that we've tracked plus the number of user suggested alternatives.
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.

path

Posts with mentions or reviews of path. We have used some of these posts to build our list of alternatives and similar projects. The last one was on 2021-07-05.
  • Code Review Request: StrongPath - Library for strongly type file paths
    5 projects | /r/haskell | 5 Jul 2021
    Hey, thanks so much for taking the time to respond and great job on hpath :)! I was using `path` extensively until we mostly replaced it with `strong-path`, so I know it pretty well, and I was aware of the other two libraries but never used them. However, they all do seem to approach paths in unique way, and I imagine are probably each good for specific set of use cases - in our use case, `strong-path` feels like the best match at the moment. My main drive regarding the features I wanted in `strong-path` was what I felt was missing while using `path`, which we mostly used while writing `Wasp-lang` compiler -> we were using `path` (and now `strong-path`) on many places in the codebase. Therefore I am certainly biased toward our use case, although I also believe it should translate pretty well to what I imagine (emphasis on "imagine" :D!) are common use cases. a) The reason why I added distinction between System/Windows/Posix was exactly to ensure that functions work reliably across both platforms! If you use `Path System` (`type Path' = Path System`) you get file path that uses standard of the OS it is executing on. This is the same thing you get if you use `Path` from `path` library. So if you are working with files on the disk, you will use `Path System` / `Path'` and you can know this code will execute reliably both on Windows and on Unix. I assume this is how `hpath` also works, since there is no mention of posix/windows distinction? On the other hand, if you need to ensure that filepath is always treated as Posix, regardless of OS on which it is executing, you would use `Path Posix`. I had a need for this because we are manipulating javascript import paths and those are always Posix. In `path` library this could now be achieved by importing `Path.Posix` and working directly with it, but I find the way we do it in `strong-path` to be more elegant / integrated. Also, this is working correctly in `path` only since recently -> I wrote a PR that fixed the problems where Path.Posix/Windows was not behaving consistently on different platforms (https://github.com/commercialhaskell/path/pull/167). Additionally, I really like that you can't mix the Posix path with System path or Windows path! While mixing Posix path with System path will work on Unix, since Unix is using Posix, it will not work on Windows, which means we have code that does not work consistently on different platforms. Instead, with `strong-path`, you can be very verbose about what kind of path is your path -> is it using whatever OS is using, or is it something specific (posix/windows), and there is no accidental mixing. I now mostly ended up explaining how this works instead of directly addressing your concerns, but I feel like this should cover them, unless I understood them wrong? b) Interesting! I can understand the idea of not specifying if something is file or directory. But I saw how they are using this File/Dir distinction in `path` and it made a lot of sense to me. From my experience so far, I was never yet in a situation where I didn't know if something was file or dir, and on the other hand, knowing that gives us extra "powers", like for example ensuring that you can't concatenate dir to a file (file dir). What do you mean by whether something is a file or directory changing during the course of the execution -> could you give me an example? Regarding signaling the intent -> I don't think this library should try to reflect the reality of the world, in the sense that if you get the path to a dir you can be sure that dir exists. Maybe it is yet to be created. But I like the idea of catching the intent in the type -> otherwise I would be just writing it in the comments next to the function declaration. Maintaining invariants -> I can't be sure, but I did write a pretty extensive suite of tests and we use it every day so we caught a lot of problems and I hope not many are left. But I see this just as a "debugging" problem -> the older the library is, the more we will be sure it is handling them well. Parser and what is a valid path -> piggy-backed on `path` mostly so that is something (I am using their parsers mostly), but I agree, this is not a simple problem, I am sure that are some unusual paths which might or might not parse validity as expected. But I believe at the moment it works well for the usual cases and I expect we will handle unusual ones as they come. Thanks for the kind words regarding the documentation :D! I feel it could be made more approachable yet but I haven't managed to figure out how to best do it yet. Do you have any suggestions on ensuring library maintains the variants? I would like to use QuickCheck at some point but haven't gotten to it yet, probably that would be a way to go? Also, do you maybe have any suggestions on how to decrease the duplication in the implementation? Thanks a lot!
    5 projects | /r/haskell | 5 Jul 2021

path-io

Posts with mentions or reviews of path-io. We have used some of these posts to build our list of alternatives and similar projects.

We haven't tracked posts mentioning path-io yet.
Tracking mentions began in Dec 2020.

What are some alternatives?

When comparing path and path-io you can also consider the following projects:

fswatch

btrfs - Haskell bindings to the btrfs API

fsnotify - Unified Haskell interface for basic file system notifications

partly - A Haskell library and command-line tool to create, inspect, and alter master boot records.

plan-b - *DEPRECATED* Failure-tolerant file and directory editing for Haskell

binary-file - read and write binary file use quasi quotation

ltext - λtext - higher-order file applicator

hpath - Typed filepath in haskell