spago | contained Machine Learning and Natural Language Processing | Natural Language Processing library

Unique names of packages have traditionally been enforced by the packages being uploaded to bower. Bower doesn't accept new packages anymore. New packages must now register in a specific repository until we have a working registry.

One important property of a scope is that you have to be the owner of an organisation to publish packages under your scope. Meaning, if you know that Google owns @google, all packages starting with @google/ are published by that organisation. In PureScript, while you can prefix your package in any way you want, this does not prevent others from naming them after your organisation.

package-sets has groups. But groups are just files that organise packages of one author in one file. They do not reflect in the package names. I also don't think that this is currently a concern of the working group that is working on the new registry. PureScript is very small as a community and there are not that many packages. The package sets are manually maintained.

There is another level to this. Packages have names, but also modules have names. I have discussed briefly, if I should name a module after another one (e.g. Data.BigInt). People were not a fan even if it would support the same interface as a "drop in replacement". It is considered bad manners or bad practice to use an existing name. So basically people simply try not to name modules after other modules.

Overall it is not perfect, but the ecosystem is so small that it doesn't cause any big problems.

Apparently the package author hasn't found the time to publish the new version to the package set yet. No biggie, Spago allows local overrides too.

As long as the GitHub repo has a tag v1.0.0, you can tell Spago to use that particular version by modifying the package set in your packages.dhall file:

Just remove the package make from spago.dhall, that's it.

npm has to have a special command for this, because node doesn't care what's in package.json, it will pick up any packages that are in node_modules. This means that npm uninstall has to remove the package from package.json, but then also delete it from node_modules, was well as all its dependencies.

Spago, on the other hand, doesn't need to do this, because spago.dhall is the single source of truth. Even if the package files are present inside the .spago directory, they will not be used in compilation unless the package is also mentioned in spago.dhall

This also works the other way around: if you just add a package to spago.dhall, Spago will automatically download it next time you run any Spago command.

The mental model is that of a Haskell developer, which is what most PureScript developers used to be, and many still are. :-)

But more seriously, the mental model is having multiple "projects" in a "solution", which is the model of Haskell's de-facto standard package manager, Stack. In Haskell this situation is very common, in PureScript - much less so, but still not unheard of.

In a situation like this it's usually beneficial to have all the "projects" to share a common set of packages, which are all guaranteed to be "compatible" with each other, which simply means that they all compile together and their tests pass. In Haskell Stack this common set of packages is defined in stack.yaml. In Spago - it's packages.dhall.

Once you have this common base set of packages established, each individual project may pick and choose the particular packages that it uses. In Haskell Stack this is specified either in package.yaml or in .cabal (the latter being phased out). In Spago - it's spago.dhall.

But of course, when you have just the one project, having both packages.dhall to establish the "base set" of packages and then, separately, spago.dhall to pick some particular packages from that set - may seem a bit redundant. And indeed, it's possible to do without the packages.dhall file completely: just specify the URL of the package set directly in spago.dhall, as the value of the packages property:

In SQL SERVER 2017 + / Postgres:

The PureScript compiler creates mostly ES3 code. This is on purpose because Ecma Script is strictly backwards compatible and ES3 code runs in a ES5-, ES2015-, ES2016- (and so on) environment. This means that code created by the PureScript compiler runs even in older browsers.

If you are coming from TypeScript or Babel, you might be used to being able to choose the target. This is because these compilers work with plugins that run after each other. But the PureScript compiler does not have such a feature (since it is not transforming JS to JS like these specific compilers).

So what can be the benefit of targeting a newer version? Code size, performance and features. If you want to use new ES2015 features in your FFI code there is great news: You can make use of these features now in PureScript 0.13. There are also talks about making the compiler target newer JavaScript environments in the future for the benefits mentioned above. If someone would have to support older environments they could still add Babel to their toolchain. But PureScript is a small community project and neither performance nor code size are of a very high priority for the project (and if they were, there would probably be other optimisations that could yield much greater results).

As you can maybe infer from the README of purescript-assert, the Test.Assert module is only a super basic assertion library for authors of actual testing libraries (because they can't use their own library without causing circular dependencies).

It is therefore not supposed to give very good error stacks and location information. Packages that use assert often do a bunch of logging in between:

Found this fork that solves the problem:

https://github.com/j-nava/purescript-mongo

it was as easy as:

Firstly, that's not what spago install does. Instead of "adding a package to your project", spago install downloads all packages that are currently referenced in your spago.dhall file.

Secondly, the idea with Spago is that you don't choose a specific package version. Instead what you choose is a "snapshot", which is a collection of certain versions of all available packages that are guaranteed to compile and work together. This is a measure intended to prevent version conflicts and versioning hell (and this is similar to how Haskell stack works)

The snapshot is defined in your packages.dhall file, and then you specify the specific packages that you want to use in spago.dhall. The version for each package comes from the snapshot.

But if you really need to install a very specific version of a package, and you really know what you're doing, then you can modify the snapshot itself, which is described in packages.dhall.

By default your packages.dhall file might look something like this: