turtle depends on a deprecated library, system-filepath.

[crocket]

I tried to replace optparse-applicative with Turtle.Options which is simpler.
However, its dependence on system-filepath deterred me from adoption.

[3noch]

That particular deprecation is highly contested.

[Gabriella439]

The main reason that turtle uses system-filepath is that it's the only path library that:

• treats paths as a new type and not a synonym for String/ByteString
• has an IsString instance for paths

However, perhaps I should just take ownership of system-filepath so that it can no longer be deprecated. Would that resolve your issue?

[crocket]

I think it would.

[3noch]

@Gabriel439 Just to put it on the table: path is now my favorite library for dealing with paths. The IsString instance is missing (for good reason), but I could see an argument for turtle adding an orphan instance for a polymorphic Path given that turtle is for scripting.

That said, I can also understand reasons against using it (bad support for relative paths, more types, etc.). I would welcome an un-deprecation of system-filepath.

[vmchale]

Unfortunately, system-filepath breaks cross-compilation due to using build-type: Custom, which means bench is broken by transitivity.

(I have no interest in what solution is picked so long as that is resolved :))

[crocket]

You could replace system-filepath with http://hackage.haskell.org/package/path
There's also path-io