Pulp should handle packages, which are not named purescript-* about pulp

[bodil]

I agree. Right now this happens because it's a cheap way of figuring out which JS files are FFI files, but I don't feel very comfortable with it. Not sure which would be a better solution, though. @paf31, any ideas?

[hdgarrood]

@jutaro, do you have an example of a real situation where this causes problems? I'm struggling to imagine any.

One alternative test for whether a package is a PureScript package could be "does it contain any files ending .purs", but that solution is arguably just as ugly...

[LiamGoodacre]

We could have metadata in the bower.json which specifies that it is indeed a purescript library. Think I mentioned this to @paf31 in irc a while back, but I don't remember what he said.

[jutaro]

Hi Harry, I really have problems to image you can't imagine.

Can you imagine all c libs are called c-, all java libs, java-, all
haskell packages haskell-*?

We have some internal packages not named after this convention. This may
be a convention for the purescript ecosystem (which I adopted
for packages likepurescript-webgl or purescript-vector). But it took me
quite a time to figure out, why it stopped finding my dependencies after
I changed from grunt to pulp after the "almost disastrous meltdown" release.

So I would need to rename all the git repos to purescript-.... But I guess
purescript would be the first programming langugae to force
such a rigid naming convention.

2015-07-26 1:36 GMT+02:00 Harry Garrood [email protected]:

@jutaro https://github.com/jutaro, do you have an example of a real
situation where this causes problems? I'm struggling to imagine any.

One alternative test for whether a package is a PureScript package could
be "does it contain any files ending .purs", but that solution is arguably
just as ugly...

—
Reply to this email directly or view it on GitHub
#55 (comment).

[paf31]

Perhaps some sort of .pulp file to override the default set of assumptions is necessary now?

[hdgarrood]

Are you thinking that if a package A wants to depend on another package B which contains PureScript code and isn't named purescript-*, then you create a .pulp file inside A, which somehow specifies that B really is a purescript package? Or would B have a .pulp file that says "I am a purescript package", and then running pulp build inside A would work, because pulp would look through the dependencies for these files?

Re .pulp: I'm not really a fan of dotfiles. I don't think we gain anything by not displaying such a file by default when you run ls on unix-like systems. Also, IIRC, Windows Explorer won't actually let you create files that begin with a dot; you have to use the command line or something. I'd rather it be pulp.yaml or something (please not JSON, editing JSON by hand is a nightmare).

One way of doing it without introducing any new files could be to put "purescript" into the "keywords" property (which is an array of strings, see the spec) inside bower.json.

If we are about to introduce our own package manifest file, I think we should think very carefully about how we do it and what the implications might be.

[paf31]

I was thinking that pulp.yaml or whatever could contain overrides for the default globs that get passed to psc, among other things. Basically any overrides for the default conventions.

[bodil]

In my mind, requiring the purescript-* convention is preferable to adding a manifest file by several orders of magnitude, and there are several other solutions I'd rate considerably higher than doing so too.

Here's the obvious one: for each .purs file, if there is a corresponding .js file in the same location, simply add that as an FFI file. This would be much easier, and more precise, if Windows didn't exist and we were still passing individual files to psc, but I'd assume if we normalise it to just expanding directory wildcards and passing each directory containing *.purs files as an FFI directory too, even Windows would be able to cope.

[bodil]

I should mention, I still very firmly believe that we should maintain the purescript-* naming convention for published PS packages, because it makes life considerably easier when you're searching for packages on Bower or anywhere else, but I don't believe Pulp needs to be restricted by it.

[garyb]

I don't think Phil is talking about a manifest file for individual packages, more like a config file for the project that allows some overrides of what pulp does when executed in the current directory.

Also, there isn't really a problem with using the glob bower_components/*/src/**/*.js as we will only actually use files that a .purs file is associated with, we don't complain when there are extraneous .js files included. (Although it may have slightly worse performance due to the glob expanding more stuff first).

[garyb]

Actually, slight revision to that: It's the files that a purescript module is associated with, not a .purs file, so there is a bit more of a performance overhead: reading and scanning all .js files for a // module comment.

[hdgarrood]

It's perhaps worth noting that the purs compile API has changed since these comments were written: now, you only need to provide the compiler with a glob of purs files, and the compiler locates ffi modules automatically, by just replacing the .purs extension with .js in each file path and reading the resultant file in as an ffi module if it exists.

The default source file glob is bower_components/purescript-*/src/**/*.purs. We could replace this with bower_components/*/src/**/*.purs now: the only drawback would be that we would end up searching through more subdirectories of bower_components. I think we'd need to test in the real world to see how severe the performance impact would be, but I suspect it won't be very significant in the vast majority of cases.