spacchetti / spacchetti

dhall-driven package sets for psc-package. Mà, ho comprato una scatola di PureScript!

DEPRECATION NOTICE

This repo has been merged into purescript/package-sets

See this issue for context.

Switching with spago

If you wish to switch to the new upstream you can just run:

$ spago package-set-upgrade

(note: this will update to the latest published package-set)

Switching with psc-package

You psc-package.json should change in the following way:

• the source key would change from https://github.com/spacchetti/spacchetti.git to https://github.com/purescript/package-sets.git
• the set would need to be pointed to a release of the new repo, e.g. at the time of writing that is "psc-0.12.3-20190227"

---

---

---

Spacchetti

Mà, ho comprato una scatola di PureScript!

Dhall-driven package sets, made for forking and modifying easily. Per chi non ha paura di rimboccarsi le maniche (e arrotolare gli spaghetti).

Read the guide for more details on RTD: https://spacchetti.readthedocs.io/en/latest/

Read more about how this works here: https://github.com/justinwoo/my-blog-posts#managing-psc-package-sets-with-dhall

Are you looking for Spago? Go here: https://github.com/spacchetti/spago

The Raisin Deets

Nobody likes editing JSON. Even fewer actually like figuring out how to resolve conflicts in Git, especially if they aren't used to aborting rebases and digging up commits from reflog. Everyone complains there is no good solution for having your own patches on top of upstream changes, for when you want to add just a few of your own packages or override existing definitions.

Well, now all you have to do is complain that this repo doesn't have enough contributors, commits, maintenance, curation, etc., because those above issues are solved with the usage of Dhall to merge package definitions and Psc-Package verify on CI.

How to consume this package set

Use Spago or Psc-Package.

How files are organized

-- Package type definition
src/Package.dhall

-- function to define packages
src/mkPackage.dhall

-- packages to be included when building package set
src/packages.dhall

-- package "groups" where packages are defined in records
src/groups/[...].dhall

How to generate the package set after editing Dhall files

First, test that you can actually run make:

> make
formatted dhall files
generated to packages.json

This is how you format Dhall files in the project and generate the packages.json that needs to be checked in. Unless you plan to consume only the packages.dhall file in your repository, you must check in packages.json.

To actually use your new package set, you must create a new git tag and push it to your fork of spacchetti. Then set your package set in your project repository accordingly, per EXAMPLE:

{
  "name": "EXAMPLE",
  "set": "160618", // GIT TAG NAME
  "source": "https://github.com/spacchetti/spacchetti.git", // PACKAGE SET REPO URL
  "depends": [
    "console",
    "prelude"
  ]
}

When you set this up correctly, you will see that running psc-package install will create the file .psc-package/{GIT TAG NAME HERE}/.set/packages.json.

Testing changes to package set

To set up a test project, run make setup. Then you can test individual packages with psc-package verify PACKAGE.

Further Complaints

PRs welcome.

FAQ

How do I use this package set?

Use Spago or Psc-Package.

Can I get additional help?

Open an issue in Spago or ask on FP Slack.

Does ___ in scripts/ mean ____?

No, these are just random scripts that are used to maintain Spacchetti package sets. They are not used by Psc-Package nor are they used by Spago.

Can I use packages from Bower?

You can use anything that is a git repository, which mean every Bower dependency and others. See the local setup docs if you want to locally add them to a project: https://spacchetti.readthedocs.io/en/latest/local-setup.html

spacchetti's Issues

Needs a cooler name

Update README

Most people just want to go to https://github.com/spacchetti/spago

CI build should fail if packages.json has changes when the build process is run

Since this needs to be consumed by psc-package, the packages.json really needs to be up to date when this runs in CI 😄

Example Nix usage using package set information from this repo

I'd really like to see how generation of some NIx (through https://github.com/dhall-lang/dhall-nix) for installing dependencies. I hope it can be not very difficult for someone who knows Nix already.

as said on https://twitter.com/jusrin00/status/1009409407090819072

`from-bower.pl` does not update dependencies on existing packages

While this will fail CI a built packages.json, this is still annoying. A proper solution might include checking the json contents of an existing entry, but as for how to then delete the failing entry probably requires too much work (read: some small amount of split /,/, $json)

Ping repos to upgrade their deps

One of the problems of updating package sets is that if that some package version is not compatible with some other package in the set, then all the packages depending on this version will not be able to get into the set.

For this reason, the Stackage team has automated messages for packages: the will open an issue to your repository if your package is holding other packages new versions from being included in the set.

So we could use the same approach and have @spacchettibotti analyze dependencies and open issues to upgrade versions in packages that hold off other packages.

Since so far there is 3 ways to build a package, we shoul be able to analyze project files from bower, psc-package and spago.

Add some notes about where packages are installed in intro

e.g. .psc-package/setname/package/version/

Write more to the README

Since I need more people to help add crap, I need to write some stuff in the README about how to use my glorious perl scripts and how to work with this in general.

Speed up CI by using Psc-Package2Nix, cache Nix directories and `.psc-package2nix/`

Fetching repos is so damn slow, it makes updating package sets just that much more annoying. Almost everything else is in place to do this, so this only needs some trial and error with caching and such.

See below, where while the limitation of slow repo fetching has been largely addressed by caching and using Nix, but the problem remains that psc-package verify is slow.

Mac install notes

Here is how I managed to get everything working on OSX without nix:

brew install dhall-json
cabal update && cabal install dhall
PATH=$HOME/.cabal/bin:$PATH make

Specify minimum compiler version in package-set release

As detailed in purescript/spago#98 (comment), we should start prefixing releases with the minimum compiler version in which the package-set is expected to work, as purescript/package-sets does already

Port Perl to Haskell

This is a follow up on a conversation we had on slack. There I suggested that the perl scripts in the scripts could be executables written in Haskell.

There are pros and cons to this suggestion:

Cons

• Aeson is more far more annoying than jq for pulling data out of a JSON
• Hackage dependencies can and will break; scripts avoid dependency hell a lot better
• Probably should have CI to make sure the PRs don't break the build
• Haskell is harder to rapid prototype than perl scripts

Pros

• Spacchetti could be published to Hackage, which makes for easier installs with cabal install spacchetti, nix-env -iA nixpkgs.haskellPackages.spacchetti and so on.
• Dhall and psc-package are written in Haskell. Haskell is a natural fit for gluing them together.
• In the long run pure functional code is more maintainable than shell scripts

---

I have some spare cycles right now to do the port, but perhaps this is premature. So I'll wait for you to give me the go ahead...

Couldn't find node.js

Assuming:

cat psc-package.json
{
"set": "local",
"depends": [
"prelude",
"psci-support",
"lists",
],
"name": "psc-getting-started",
"source": ""
}

psc-package repl

I am getting:

import Prelude
import Data.List
range 0 999
Couldn't find node.js

Dependency order

Doing a build and comparing to the current package-sets version, there are some trivial diffs such as:

   "event": {
     "dependencies": [
+      "prelude",
       "console",
       "effect",
       "filterable",
-      "js-timers",
-      "now",
       "nullable",
-      "prelude",
-      "unsafe-reference"
+      "unsafe-reference",
+      "js-timers",
+      "now"
     ],

where the diff is only in the order of dependencies. Is the order intentional here or should dependencies always be in alphabetical order (if that's even possible)?

I guess the question is more along the lines - if this is a viable alternative to maintaining the current package-sets, then it should probably try to produce the smallest diff. Was that the intent or a consideration when spacchetti was built?

Autogenerate additional merged records with documentation via `local-setup`

IMO, it would be nice if local-setup automatically generated two things in addition to what it already does:

1. additional records that it automatically merges, making it easy to add new packages or override upstream packages
2. instructions for how to add/override packages via comments.

In other words, something like this:

   let mkPackage = -- normal stuff
in let upstream  = -- upstream dhall stuff
in let overrides = {- 
    To override packages defined in the upstream packages
    with new values (e.g. update a tag, use a different git repo, etc.),
    replace the below '{=}' with something like the following
    for each package you need to update
-------------------------------
    { packageName =
        upstream.packageName ⫽ { updateEntity1 = "new value", updateEntity2 = "new value" }
    , packageName =
        upstream.packageName ⫽ { version = "v4.0.0" }
    , packageName =
        upstream.packageName // { repo = "https://www.example.com/path/to/new/repo.git" }
    }
------------------------------- -}
    {=}
in let additions = {- 
    To add packages not defined in the upstream packages,
    replace the below '{=}' with something like the following
    for each package
-------------------------------
    { "package-name" = 
          mkPackage
              [ "dependency1"
              , "dependency2"
              ]
              "https://example.com/path/to/git/repo.git"
              "tag ('v4.0.0') or branch ('master')"
    , etc...
    }
------------------------------- -}
    {=}
in upstream // overrides // additions

Then, a newcomer can follow the instructions in the generated file without needing to understand Dhall.

Change of Date Format for releases

Apparently some people would really like to emphasize Year and Month first rather than to just use the normal western time stamp.

Current:

DDMMYYYY
09122018

Requested:

YYYYMMDD

The latter is mostly used in Asia, but would work okay for me. As the current format is already actually inconsistent between DDMMYYYY and DDMMYY, switching to the Asian format would work okay in the end.

Question: lack of newline characters in generated file via `local-setup`

When I use spacchetti local-setup, it generates the following file automatically...

let mkPackage = {- normal stuff -} in let upstream = {- upstream dhall stuff -} in upstream

...rather than something that can be easily edited as all the examples in the docs show:

   let mkPackage = -- normal stuff
in let upstream = -- upstream dhall stuff
in upstream

Is this due to wanting the code to work regardless of which OS' newline characters are being used? Could this be changed to generate something more like the second example above rather than the first?

License?

What license is the code here under, could you add to the repo?