Naming convention for purenix libraries.

[m-bock]

I noticed that the ports of the 'official' PS packages still keep the same names of their origins.

E.g. purescript-nonempty

Would it maybe make sense to name them either purescript-nix-nonempty or even purenix-nonempty. I think the purescript- prefix is a leftover from bower times. It's not mandatory for spago anymore?

[cdepillabout]

@thought2 Thanks a good question. I'm not sure what the best answer is.

Maybe @f-f has an answer (or at least an opinion)?

It looks like purescm is keeping the libraries called purescript-*, so I was originally following that lead and doing the same thing for PureNix: https://github.com/purescm

[f-f]

I can't find a precise pointer to this right now, but pulp did require the purescript- prefix for repos being published. I believe the historical reason for this is so that one could distinguish PureScript libraries from everything else on the Bower registry.
In any case, we're lifting this restriction with the new registry!

In purescm we kept the libraries with the original prefixes because they are forks of upstream libraries with the same name. We eventually want to publish the Scheme FFI layer to the Registry, but still not sure how we'll do that so the name has stayed like this all along.

[cdepillabout]

In purescm we kept the libraries with the original prefixes because they are forks of upstream libraries with the same name.

Ah, yeah, PureNix is the same way. All the current purescript-* PureNix libraries are direct forks of the upstream PureScript libraries. Mostly nothing has been changed other than the FFI files.

We eventually want to publish the Scheme FFI layer to the Registry, but still not sure how we'll do that so the name has stayed like this all along.

Oh, this is a good point. I'd been meaning to ask if libraries for alternative backends would be supported in the PureScript registry.

Whatever name we pick for these PureNix libraries, it will have to be compatible with the PureScript Registry (whether that means with a purescript- prefix, or a purenix- prefix, or no prefix, etc).

[m-bock]

Another thought about this:

I think it would be really powerful if there are FFI-less packages that in the end could be used with any backend. Those packages may still have dependencies to other libs that have FFI which would be resolved differently for each backend.

But in my current understanding it's not really possible. It would work, if the FFI libs and their forks on the PureScript side are 100% compatible. But I think it's not really possible in every case. See, for instance this section here: https://github.com/thought2/purescript-foreign/blob/main/src/Foreign.purs#L137 where I needed to enhance the API for nix specifics.