There's not really a need for this, we just need to have psc-package do the traversal to find all transitive dependencies. It should make it simpler to add a package to the set.

Requiring a hash in addition to the version tag would be a cheap additional layer of security. As it stands, a package author could maliciously amend a tag in their git repo, no?

Initializing a project using psc-package init I get a psc-package.json file that sets up prelude as a dependency.

At this point running psc-package repl, I would expect Prelude to be automatically imported as it's a dependency of the project, but it's not. Am I having the wrong idea of what is intended with this command, or is this an improvment to be made?

I have something like this in my add-from-bower PR, but we really explicitly need one for when one works with package sets to make sure everyone actually edits these correctly in alphabetical order without inconsistent formatting, since JSON is... not fun.

This would make psc-package build more declarative by not having it depend on whether you've run psc-package update or not. Stack does it and it's really nice. Would this be a good change?

I think this would be useful at least in the node.js context. Build and maintenance scripts and so on could then be expressed using purescript and simply run, while still retaining the ability to call into any relevant JS libraries. I just wanted to bring this up for discussion, I have not put any thought into how this would actually work.

For what it's worth here was the RFC to add a "script" command to stack: commercialhaskell/stack#2805.

This issue was moved here from purescript/purescript#2883

The README contains a FAQ "Can I add a dependency which is not in the package set? Not right now." This is directly under add-a-package-from-bower section. Shouldn't the FAQ be updated to say something like "yes, via Bower" now?

We should be able to publish packages to Pursuit using purs publish, by generating the two necessary JSON files in the correct format.

My apologies for having a few false starts on this, but it's been a bit of a tricky issue.

Currently, psc-package sources outputs a list of globs, which can lead to some unintuitive behavior in some shells when used as a parameter to purs commands. This certainly got me, and though my shell-fu is admittedly a bit weak, I imagine that others will find this to be hard to debug as well.

I feel like something should be done to deal with this. Perhaps the default behavior of psc-package sources should be to simply list every individual file among the dependencies, rather than the globs.

Since this project is now on low flame, may I suggest creating a document that specifies what is the vision/goals/next steps for this tool, and what are the common problems you ran into while designing it?

I know there has been a pretty big discussion about it, and I think having a clearer idea about your vision
for this tool and what you don't want it to include will lower the barrier of entry and will make it easier for others to continue your work and take this tool forward.

Could help avoid confusion like in purescript/purescript#2692.

still 0.1.0

I tried building it just now on Windows and everything seems to work.

I'd like to be able to say psc-package init --source <url> --set <tag_name>.

So I've been converting a project to use package sets and I needed a workflow for temporary changes to the package-sets repo in my fork while waiting on PRs. I noticed from the source code that its just shelling out to git and the git command being called happens to take a tag or a branch. If you try to specify a SHA it will tell you the SHA isn't a branch.

However, when you use a branch, the tool doesn't actually know how to get new updates for that branch. You have to actually delete the .package-sets subdir for your branch for it to update. I talked with someone in the IRC about it and they believe that the idea is that package sets are immutable (which seems like a good idea). If that's the case, tags fit the bill because they are effectively immutable, but branches seem like a misfeature. They are a moving target but aren't treated that way by psc-package. If we want to stick with immutability, it seems like a SHA is a better fit because it is basically analogous to a tag and the user would not infer mutability like they may with branches.

I think implementation wise, there's probably a git command to determine if a given string is a tag and if not, assume its a SHA and run a different git command depending. Thoughts?

Following on from purescript/purescript#2526. I am thinking about the architecture of psc-package, and in particular, thinking about how it differs from Stackage in that Stackage is an extra layer in front of Hackage, and Hackage is a centralized package registry which provides:

• uniqueness of names, i.e. it makes it easy for people to know which package you mean when you just say "profunctors" or "st" or something.
• a canonical location for information such as dependencies and version bounds, which means that the work of package authors in tracking down version bounds can be reused by everyone, regardless of which package manager they are using
• protection against packages going missing as a result of mutation of git tags or deletion of repositories.

I also think that having a centralised registry which is separate from curated package sets provides an important option for publishing packages for authors who might struggle to find time to keep their packages up to date; if the only option is submitting to a package set, I think we risk discouraging people from publishing their packages at all.

Another related issue that has just occurred to me: I think it's quite far from ideal that if someone were publishing their packages only through psc-package and also uploading them to Pursuit, the information about dependencies and bounds which would be passed to purs publish via --manifest psc-package.json on Pursuit would essentially be meaningless. Since the package author would not actually be using it in the course of developing their package, I expect in most cases it would quickly go out of date.

It is probably obvious by now that I would quite like to have a centralised package registry of some kind. However, I appreciate that this would amount to quite a lot of work. So I'm really opening this issue to ask: do you agree that it is worth addressing these issues by creating a centralised registry and modifying psc-package to use it, and if not, is that because of how much work it would be or because of something else?

related: #43

Would there be any interest in having a docs command that generates offline documentation for the package and its dependencies using purs docs?

We construct several directory and file paths using </>. If a package set, package or tag name has path parts in its name such as .., then this allows psc-package to create files outside the project directory. This is obviously a bug, and possibly a security issue, so we should disallow such filenames.

If I clone a repo that uses psc-package, I get a psc-package.json file, but no .psc-package directory. Then, as far as I can see, nearly every command complains that either .psc-package/psc-0.11.6/.set/packages.json does not exist or psc-package.json already exists.

The only way I've found to get psc-package build working is to call psc-package install prelude to kick things off.

Is there a less hacky way to do it?

(If I'm missing something obvious, my apologies for being dense!)

I would really like to have this, and doing some initial searching I've found that there's no real way to get the information we need that the Bower CLI/Node library can provide through any APIs like libraries.io i.e. we need to know what dependencies a project has, and bower info seems to be the only convenient way to get this.

So I don't really have a good idea on how this should be done other than to call out to the Bower CLI and parse the JSON that it outputs. This would require that anyone who wants to use a add-from-bower feature to have Bower installed, but at least don't require them to have to install node or set up anything else (because otherwise we'd probably be stuck having an entire npm package here).

Thoughts?

Similar to the capability in Haskell Stack, would like the ability to add packages that are not in the configured package set. Ideally it would allow for overriding curated version of a package in addition to simply adding an uncurated package.

Primary use case for me is the ability to use our domain-specific libraries.

Secondary use cases include using a needed library before it is added to package-sets, using a homegrown general-purpose library before releasing it to the community, and experimenting with a library's upcoming features before its version is updated in package-sets.

Would be nice to have this documented in the README.

I wanted to try psc-package for a new project based on the node-telegram-bot-api from @justinwoo, but ran into several issues which I still don't understand. Maybe they are bugs, maybe just documentation issues, but here is a transcript of what I tried to do. Sorry for the lengthy issue, but I just don't know what I did wrong, so I hope people will take the time to skim through it and give me some insights and distill the improvements on psc-package

$ psc-package init
$ psc-package install node-telegram-bot-api
Package node-telegram-bot-api does not exist in package set

Right, I knew that, but I already saw that there is another package set from Justin that does contain it!
Editing psc-package.json to have source "https://github.com/justinwoo/package-sets.git", then:

$ psc-package install node-telegram-bot-api
Package node-telegram-bot-api does not exist in package set

Oh, ok.. maybe it needs some sort of update.. What is the difference between update and updates?

$ psc-package update
Updating 1 packages...
Update complete

$ psc-package install node-telegram-bot-api
Package node-telegram-bot-api does not exist in package set

$ psc-package updates
Checking 187 packages for updates.
..........

$ psc-package install node-telegram-bot-api
Package node-telegram-bot-api does not exist in package set

$ psc-package init
psc-package.json already exists

$ rm -rf .psc-package/
$ psc-package update
warning: Could not find remote branch psc-0.11.7 to clone.
fatal: Remote branch psc-0.11.7 not found in upstream origin

This I really do not understand. Is it a problem with the package set? But there is no mention of the psc in the package set... Maybe a bug?

Let me try to init a project with the new package-set from the start. I remember reading some flag to do this..... But cannot find in the README or in the --help how to do that :(

Eventually found that it is in the message that psc-package init gives. This could be mentioned in the help or readme as well?

$ rm psc-package.json
$ psc-package init --set https://github.com/justinwoo/package-sets.git
Initializing new project in current directory
warning: Could not find remote branch https://github.com/justinwoo/package-sets.git to clone.
fatal: Remote branch https://github.com/justinwoo/package-sets.git not found in upstream origin

Wat? Maybe wrong format?

$ psc-package init --set https://github.com/justinwoo/package-sets
psc-package.json already exists
$ rm psc-package.json
$ psc-package init --set https://github.com/justinwoo/package-sets
Initializing new project in current directory
warning: Could not find remote branch https://github.com/justinwoo/package-sets to clone.
fatal: Remote branch https://github.com/justinwoo/package-sets not found in upstream origin

Ok... I don't know what to try anymore, giving up :(

(One day later)

Initializing new project in current directory
Using the default package set for PureScript compiler version 0.11.7
(Use --source / --set to override this behavior)

Oh.. I see now that --source and --set are not just aliases, as I assumed..

$ psc-package init --source https://github.com/justinwoo/package-sets.git
Missing: --set ARG

Usage: psc-package init [--set ARG] [--source ARG]
  Create a new psc-package.json file

Why not just the default set, as psc-package init does?

$ psc-package init --source https://github.com/justinwoo/package-sets.git --set 0.11.7
Initializing new project in current directory
warning: Could not find remote branch 0.11.7 to clone.
fatal: Remote branch 0.11.7 not found in upstream origin

Ah, so the set is some branch on the package-set? Does not seem to be that way? How to figure out what a valid set is?

Now really giving up :(

psc-package sources outputs globs that, in some cases, will miss certain modules.

For example, the glob output for the Prelude is .psc-package/psc-0.11.3/prelude/v3.0.0/src/**/*.purs. However, Prelude.purs lives directly in the src directory.

Can't hurt

psc-package downloaded from the release notes shows 0.2.0 instead of 0.2.3

purs is an available command in my terminal and pulp doesn't have any problem to find it, however psc-package cannot find it:

psc-package.exe: purs: createProcess: does not exist (No such file or directory).

In PowerShell:

> .\psc-package init

When run from cmd prompt:

>psc-package init
Initializing new project in current directory
Using the default package set for PureScript compiler version 0.11.7
(Use --source / --set to override this behavior)
Updating 1 packages...
Updating prelude
>

When run from Cygwin:

$ psc-package init
Initializing new project in current directory
Using the default package set for PureScript compiler version 0.11.7
(Use --source / --set to override this behavior)
fatal: could not create work tree dir '.psc-package\psc-0.11.7\.set': No such file or directory
$

After making the parent of the above folder manually, i.e.:

$ mkdir -p .psc-package/psc-0.11.7

it proceeds, only to fail on the next one:

$ psc-package init
Initializing new project in current directory
Using the default package set for PureScript compiler version 0.11.7
(Use --source / --set to override this behavior)
Updating 1 packages...
Updating prelude
fatal: could not create work tree dir '.psc-package\psc-0.11.7\prelude\v3.1.1': No such file or directory

After creating this one too:

$ mkdir  -p .psc-package/psc-0.11.7/prelude

it finishes fine.

This is perhaps due to using \ instead of / for path separators.

Side note, all this is after manually copying purs.bin to purs.exe due to #34.

I'm not sure what wording you'd use but one thing I found confusing about this repo is there doesn't appear to be actual instructions on how to install it. I found the releases page on a hunch and it had exactly what I needed.

Possibly a separate issue but in both the main purescript binaries and psc-package, they don't offer suggestions on how to install the binaries. Typically I run sudo install -t /usr/local/bin psc* but I've learned this the hard way from installing NPM which also lacks installation instructions for their binaries.

Is there any plan to publish psc-package to hackage/stackage?

example

$ psc-package build --help
Usage: psc-package build [-d|--only-dependencies] [`purs compile`-options]
  Build the current package and dependencies

Available options:
  -d,--only-dependencies   Compile only the package's dependencies
  `purs compile`-options   Options passed through to purs compile; use -- to
                           separate
  -h,--help                Show this help text

The documentation format for "purs-compile-options" seems to stray from UNIX command line norms. Ideally the usage line would more clearly illustrate the usage of -- to separate pass-through arguments.

Here is what stack does, for comparison:

$ stack exec --help
Usage: stack exec CMD [-- ARGS (e.g. stack ghc -- X.hs -o x)] ([--plain] |
                  [--[no-]ghc-package-path] [--[no-]stack-exe] [--package ARG]
                  [--rts-options RTSFLAG]) [--help]
  Execute a command

I installed everything with npm install -g purescript pulp psc-package but psc-package isn't working, why?

> psc-package --help
events.js:160
      throw er; // Unhandled 'error' event
      ^
 
Error: spawn C:\Users\me\AppData\Roaming\npm\node_modules\psc-package\vendor\psc-package.exe ENOENT
    at exports._errnoException (util.js:1022:11)
    at Process.ChildProcess._handle.onexit (internal/child_process.js:193:32)
    at onErrorNT (internal/child_process.js:359:16)
    at _combinedTickCallback (internal/process/next_tick.js:74:11)
    at process._tickCallback (internal/process/next_tick.js:98:9)
    at Module.runMain (module.js:606:11)
    at run (bootstrap_node.js:394:7)
    at startup (bootstrap_node.js:149:9)
    at bootstrap_node.js:509:3

This maybe somewhat big change, but how about using YAML as psc-package file format, psc-package.yaml? YAML provides some merits such as comment and flexible syntax.

I guess this don't need to be so breaking, if we leave JSON parser for backward compatibility and just create YAML for new projects. Surely it can just be dropped.

It would be great if the single entrypoint to purescript was psc-package, by allowing one to install (a version of) purescript directly from the tool. Something akin to stack install.

I want to push newest version of psc-package to NixOS package repository, but it doesn't provide such an old version of turtle like ==1.3.*.
I've tested psc-package compilation against ==1.4.5 and it works with really minor change (hiding nub function from Turtle). I'm not sure if we want such a version specification or maybe ==1.4.*.
Should I provide a pull request with turtle update? If so how to specify turtle version?

Sorry if this is already the case. Using psc-packages with success to build my project, but now I'm wrapping it up as a Nix expression, and it would help to be able to separate in two steps:

1. Only creates .psc-package based on the psc-package.json file. Fetches from git and stuff. Doesn't build.

2. Only builds, doesn't try to access network or in other way update .psc-package.

This would let me effectively cache 1), and rerun 2) relatively fast.

1. might already be satisfied by some command (install? update?), but I'm not sure. For 2), psc-package build seems to try to check the updates (though I'm on a former version from stable Nix channel).

Thank you!

I'm not sure whether this belongs in this repository or purescript/purescript

Right now, psc-package downloads packages and places them into the .psc-package folder:

.psc-package
└─┬ psc-0.10.2
  └─┬ prelude
    └─┬ v2.1.0
      └── ...

Instead, I propose for it to install packages into a single cache folder, and then create a symlink in .psc-package:

.psc-package
└── psc-0.10.2 -> $XDG_CACHE_HOME/psc-package/package-sets/psc-0.10.2

$XDG_CACHE_HOME
└─┬ psc-package
  ├─┬ packages
  │ └─┬ prelude
  │   └─┬ v2.1.0
  │     └── ...
  └─┬ package-sets
    └─┬ psc-0.10.2
      └── prelude -> $XDG_CACHE_HOME/psc-package/packages/prelude/v2.1.0

Notice that there are actually two symlinks:

• .psc-package/psc-0.10.2 symlinks to $XDG_CACHE_HOME/psc-package/package-sets/psc-0.10.2

  The reason is: if multiple PureScript programs use the same package set, it only needs to be downloaded once.

• $XDG_CACHE_HOME/psc-package/package-sets/psc-0.10.2/prelude symlinks to $XDG_CACHE_HOME/psc-package/packages/prelude/v2.1.0

  The reason is: if the same package+version is included in multiple package sets, it only needs to be downloaded once.

This has a few benefits:

• It saves a non-trivial amount of internet bandwidth.

• It saves time, since the files do not need to be downloaded/unzipped/untarred/copied repeatedly.

• It saves disk space, since only a single copy of a package or package set needs to exist (per version).

• It avoids unnecessary file writing, which is important on SSDs.

P.S. It's probably a good idea to make everything inside of $XDG_CACHE_HOME/psc-package read-only. If it is read-write, and if somebody modifies their local .psc-package folder, then it will affect all PureScript programs on their computer (because of the symlinks). This is very unexpected behavior.

P.P.S. This proposal uses the $XDG_CACHE_HOME env var, which defaults to $HOME/.cache/. That is the correct location to use on *nix. Windows should probably use %LOCALAPPDATA% and Mac should probably use ~/Library/Caches/

You might find this useful, though it does not seem to support Mac.

This is a real annoyance when wanting to make a single change when you haven't already downloaded everything. psc-package verify choco-pie should only ensure installation of choco-pie's dependencies and its reverse dependencies.

It's not a big deal, but I think having commands that only differ by s might be confusing.

Hi, I have installed nom package on a windows machine but the vendor subfolder doesn't contain the windows binary executable.

As a new psc-package user I struggled yesterday to perform the most basic of tasks, an initial package set install.

Neither the help text, nor the README provide any guidance in this regard. In fact, the README seems to target package authors with little thought to package users.

With some help I discovered psc-package update was what I needed, but that command and the associated help text Update dependencies have different semantics from an initial install.

I propose improving the help text for a few of the commands:

init Initialize a new package -> Create a new psc-package.json file
update Update dependencies -> Install or update package dependencies
build Build the current package and dependencies -> Update dependencies and compile the current package

Additionally, a line near the top of the README regarding initial install would be helpful. Something along the lines of:

# installs the project dependencies listed in psc-package.json
psc-package update

nwolverson mentioned that one can invoke psci directly using

psci `psc-package sources` 'src/**/*.purs'

However it is not entirely straightforward to discover this when you are not familiar with psc/i very much.

I'd like to suggest a psc-package repl command that will run the mentioned command as well as a flag for it (for example: --only-dependencies) that will not include 'src/**/*.purs' (so you can have a repl with your deps even when you code doesn't compile yet).

I could probably add this command myself if needed.

Hey! So! Sorry to sealion into your repo like this, but I was having some thoughts and I remembered the ongoing plight of purescript folks as far as package management goes.

It turns out I've been overhauling and rewriting a pretty significant chunk of the npm internals related to downloading/caching/extraction/etc, and the product of that work turned out to be https://npm.im/pacote. It's a completely standalone library and it pretty much supports anything you need in order to install stuff from the npm registry itself. Or, you know. It also has git repository support.

Now, I don't know if y'all are remotely willing to use javascript stuff under the hood to get this implemented, but I'd definitely be interested in helping out, refactoring things, adding features, etc, if it meant it would be of use to y'all. I think pacote would benefit immensely from more than one client app. And y'all would be able to rely on a package that's pretty core to a very widely-used package manager. This stuff turns out to be a lot of work. :)

There's a few constraints for this, of course: this still assumes things are semver (although you could disable support for npm-style semver range resolution. I could even provide a hook for parsing out the multiple versions in packuments). It also assumes you're using the various dependencies fields, though tbh you can almost certainly make those look literally however you want cause it mostly just copies them over. If you want specific packument fields available, though, we can find ways to make that work. I don't mind changing the manifest logic a bit or providing hooks 👍

But anything having to do with node_modules, dependency resolution ("ok I have this package, which others should I get"), any logic around how to prepare/finalize/script packages -- that's all completely external to this module. Since it's just a library, all the UX

Sorry for the blob of text! I hope this is interesting!

My understanding so far is that psc-package is meant to replace bower . On the other hand pulp is still useful. Is that correct ? Is it possible to use psc-package together with purs without requiring a third tool ?

PureScript by Example does not mention psc-package at all and would suggest the use of bower to tackle dependencies. Does it mean that psc-package is not ready for broad user consumption yet ?

At this point, I have found the psc-package story quite confusing. What seems to be missing is a section about simple usage patterns. I have managed to build a project with psc-package but it is still unclear to me if I should bundle using purs or pulp.

Thanks for your help.

Would be nice to have the semantics of package.json contained within a separate lib to ease the development of complementary tools.

I can give examples how other ecosystems do this:

Haskell:

• Maintainer pushes new versions on hackage, where all are available
• cabal does version/dependency resolution
• There is a matrix builder which tests versions of the package against different compiler versions
• A maintainer can also upload her package to stackage, which is a coherent set of packages that work together, with LTS support

Nix:

• nixpkgs is a giant monorepo for all packages
• This way, you automatically get a semi-coherent package universe with each commit, if you test reverse dependencies of each change (which nix can do because of its hash-based properties)
• Every few months, a stable release is split of, with as many packages patched & working as possible

Haskell in nixpkgs:

• Once a week, a maintainer updates the package versions in nixpkgs
• The Stackage set is taken as base, the missing hackage packages are taken from hackage
• broken packages can be overwritten in multiple stages (e.g. disabling tests for a compiler version) until upstream fixes the bugs

I came to love the monorepo approach, because you automatically get a high level of consistency (provided the right CI integration) and each commit can be seen as snapshot in time. With the package-sets repo, there is already the basis for such an approach, though missing checksums and resolved versions (maybe these should be added by psc-package after resolving; see also the yarn package manager).

Another idea is to use as much already existing software from other projects as possible:

• The haskell matrix builder should be reusable.
• By converting psc-package output to nix packages, nix can be used to provide continuous integration, maybe even with https://nixos.org/hydra/.

My inner programmer hates how every language under the sun reinvents package management (except of course the inner compiler-specific integration). nix is a nice meta-solution, though incompatible with Windows at the moment, so only usable as an additional layer.

When running psc-package build I sometimes get the error psc-package: failed to create OS thread: Cannot allocate memory. The command still seems to make progress, so after running it a couple times it succeeds. I don't think I'm actually running out of memory -- I have a few gigs free when I run the command and according to xmobar it doesn't get used up.

Version details (exhaustive setup is here):

$ psc-package --version
0.2.0
$ purs --version
0.11.6

Example error occurances:

$ psc-package build
Updating 45 packages...
Updating assert
Updating arraybuffer-types
Updating arrays
Updating console
Updating control
Updating distributive
Updating datetime
Updating bifunctors
Updating eff
Updating dom
Updating either
Updating foldable-traversable
Updating enums
Updating exceptions
Updating generics
Updating functions
Updating gen
Updating identity
Updating globals
Updating foreign
Updating integers
Updating invariant
Updating lazy
Updating js-date
Updating maps
Updating lists
Updating maybe
Updating newtype
Updating media-types
Updating nonempty
Updating math
Updating monoid
Updating partial
Updating nullable
Updating prelude
Updating proxy
Updating psci-support
Updating strings
Updating st
Updating tailrec
Updating tuples
Updating transformers
Updating type-equality
Updating unfoldable
Updating unsafe-coerce
psc-package: failed to create OS thread: Cannot allocate memory

$ psc-package build
Updating 45 packages...
Updating lazy
Updating lists
Updating math
Updating maps
Updating media-types
Updating maybe
Updating monoid
Updating nonempty
Updating newtype
Updating nullable
Updating partial
Updating prelude
Updating proxy
Updating psci-support
Updating strings
Updating tailrec
Updating transformers
Updating tuples
Updating type-equality
Updating st
Updating unsafe-coerce
Updating unfoldable
psc-package: failed to create OS thread: Cannot allocate memory

$ psc-package build
<succeeds this time>

After running into this issue I installed psc-package.exe from the releases here. But it doesn't create the psc-package.json file:

> psc-package --help
Usage: psc-package COMMAND
  Manage package dependencies

Available options:
  --version                Show the version number
  -h,--help                Show this help text

Available commands:
  init                     Create a new psc-package.json file
  update                   Install or update package dependencies
  uninstall                Uninstall the named package
  install                  Install the named package
  build                    Update dependencies and compile the current package
  repl                     Open an interactive environment for PureScript
  dependencies             List all (transitive) dependencies for the current
                           package
  sources                  List all (active) source paths for dependencies
  available                List all packages available in the package set
  updates                  Check all packages in the package set for new
                           releases
  verify-set               Verify that the packages in the package set build
                           correctly
  verify                   Verify the named package

psc-package 0.2.5

> psc-package init
Initializing new project in current directory
psc-package: purs: createProcess: does not exist (No such file or directory)

But purs is in PATH:

> where purs
C:\Users\me\AppData\Roaming\npm\purs
C:\Users\me\AppData\Roaming\npm\purs.cmd

> purs --help
Usage: purs.bin COMMAND
  The PureScript compiler and tools

Available options:
  --version                Show the version number
  -h,--help                Show this help text

Available commands:
  bundle                   Bundle compiled PureScript modules for the browser
  compile                  Compile PureScript source files
  docs                     Generate Markdown documentation from PureScript
                           source files
  hierarchy                Generate a GraphViz directed graph of PureScript type

                           classes
  ide                      Start or query an IDE server process
  publish                  Generates documentation packages for upload to
                           Pursuit
  repl                     Enter the interactive mode (PSCi)

purs 0.11.7

Hi,

I'm using psc-package with a forked package-set. I am running into this error, which was pretty unhelpful. Is it possible to get better parsing errors? I played around with Aeson but the best I could get with eitherDecodeStrict was "Error in $: Failed reading: not a valid json value". I am not that familiar with Aeson so maybe there is a better solution?

This also applies to psc-package.json, I believe.