Typed filepath (by commercialhaskell)

Path Alternatives

Similar projects and alternatives to path

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a better path alternative or higher similarity.

path reviews and mentions

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 | | 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 ( 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 | | 5 Jul 2021


Basic path repo stats
about 1 year ago
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives