directory-1.3.8.0 violates the Haskell PVP

[andreasabel]

From the directory-1.3.8.0 CHANGELOG:

Modules in directory are no longer considered Safe because the System.OsPath dependency is no longer Safe.

This means that all packages that use directory < 1.4 and import safe System.Directory are broken.

In the wild, this looks like this:

Building library for MissingH-1.5.0.1..
...
src/Network/Email/Sendmail.hs:35:1: error:
    System.Directory: Can't be safely imported!
    The module itself isn't safe.
   |
35 | import safe System.Directory
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^...
...
Error: cabal: Failed to build MissingH-1.5.0.1

Standard action path:

• deprecate directory-1.3.8.0 on hackage
• revise it to become unbuildable
• release as directory-1.4

ATTN: @Rufflewind

[Rufflewind]

@bgamari @hasufell System.OsPath is not Safe and so directory transitively also became non-Safe. @andreasabel considers this a PVP violation, which leaves us with two options:

1. Restore the Safe status in System.OsPath, send out a minor release of filepath, and then mark filepath-1.4.100.0 as deprecated; or

2. Retain the non-Safe status quo, send out a major release of directory-1.4.0.0, and then mark directory-1.3.8.0 as deprecated.

Any thoughts on which approach to take?

[hasufell]

I feel the specification is not very clear on that matter

https://pvp.haskell.org/

@Bodigrim

I personally think that "compiles without code change" is not really what non-breaking or "other" changes from PVP spec demand.

Then again, if you consider "Safe" as part of the API, then you could argue different. The spec only implicitly defines "API".

[andreasabel]

I agree that the PVP does not mention anything on safe vs. non-safe. While nothing violates the letter of the PVP, certainly going from safe to unsafe violates the spirit of the PVP.
The spirit (and dominant practice) is that it is sufficient to set a major version upper bound for your dependencies (with some exceptions, e.g. when you define orphan instances). So, if you make changes to your package that can break downstream packages, you need to bump the major version.

[hasufell]

This would mean filepath itself also needs a major version bump. This is what I initially planned to do, but GHC team said that will create more work for them.

@bgamari @mpickering

[Bodigrim]

There is a never ending trail of destruction caused by Safe Haskell. Friends do not let friends use {-# Safe #-}. I’m very serious, please just don’t.

[andreasabel]

Friends do not let friends use {-# Safe #-}.

This message should go to the haskell-language-server folks, summoning @jneira.
In my case (MissingH) the safe imports were added (Feb 2022) by the HLS tactic that creates explicit import lists (a terribly useful tool otherwise, maybe this is a flaw).

The GHC crowd seems rather undecided what to do with SafeHaskell, e.g. see this unresolved issue from 2014: https://gitlab.haskell.org/ghc/ghc/-/issues/8745

Reported upstream to PVP:

• The PVP should include advice about SafeHaskell pvp#44

[Bodigrim]

I suggest both directory and MissingH to remove Safe pragmas. This is a misfeature which makes everything too fragile.

Bumping major versions of filepath and directory is an extremely costly change for the ecosystem. According to the letter of PVP they are not in breach, and my opinion is that it's Safe Haskell as a feature who is at fault with PVP here. There are only handful users of Safe Haskell, and it seems less costly to revise them by adding directory < 1.3.8.0 bound.

[andreasabel]

Serokell hackage search for import safe System.Directory only finds MissingH. Fringe use indeed, and I only started the import safe thing because HLS suggested it (didn't even know about this syntax).

... MIssingH to remove Safe pragmas.

Will do, seems the most pragmatic course of action.

[andreasabel]

Serokell hackage search for import safe System.Directory only finds MissingH.

Actually, I overlooked lio-fs which is a (likely academic) security library so they crucially rely on SafeHaskell. I revised their packages to directory < 1.3.8:

• Revised to directory < 1.3.8 on hackage PLSysSec/lio#56

In my case (MissingH) the safe imports were added (Feb 2022) by the HLS tactic that creates explicit import lists (a terribly useful tool otherwise, maybe this is a flaw).

I might have been unjust in my assessment here because I misremembered. HLS only adds safe to import when the importing module is declared Safe (see my relevant commit to MissingH). So, my apologies to the HLS developers, their logic is correct.

[mpickering]

This would mean filepath itself also needs a major version bump. This is what I initially planned to do, but GHC team said that will create more work for them.

My understanding is that System.OsPath is a new module, so that a minor bump is still fine for filepath.

The issue here seems to be that System.Directory (an existing module) changes its safety status, I agree with @Bodigrim that removing the use of SafeHaskell is the best thing to do..

Thanks everyone for the discussion about this.

[andreasabel]

For package MissingH, I am dropping LANGUAGE Safe for all modules importing System.Directory in this PR:

• Bump to 1.6.0.0, allow directory-1.3.8 and unix-2.8, disabling Safe for some modules haskell-hvr/missingh#63

[Rufflewind]

Are there any outstanding issues that remain here?

If not I will close this. Thank you all for the discussions.