Local packages in mono repos

[m-bock]

Consider a setup as described here: https://github.com/spacchetti/spago#monorepo

When spago2nix is run inside app1 it just produces a comment for the local package:

  # lib1 is a Local package in (Local "./../lib1")

(See https://github.com/justinwoo/spago2nix/blob/96d0fd2ab96e62ad5fa2d5f0dd086652a2ac2901/src/Generate.purs#L208)

With this the nix build fails because of a missing module from the dependency.

How should this be handled?

Should we just generate something like this instead of the the comment?:

    "lib1" = pkgs.stdenv.mkDerivation {
        name = "lib1";
        src = ./../lib1;
        phases = "installPhase";
        installPhase = "ln -s $src $out";
      };

[justinwoo]

Thanks for the PR, but I don't think this is what I would want to do. The problems are that

1) trying to use the PATH as a source would mean you still generate derivations that rely on the user environment 2) you would end up putting every file tree version of the local package in the store, meaning that not only do you get git reversions but also revisions of any file in the directory 3) this will not produce the same result as spago build, which is not necessarily a huge problem, but it is a goal for me to generate a .spago/ directory with the correct packages inside, without shims that are treated differently by spago2nix build

What I think should be done is to write this information out somewhere in spago2nix generate (if not already available otherwise), and to adjust the build to feed in source globs. It's kind of a pain, but local packages are also an abomination anway

[m-bock]

Ok, I think I get your point. What do you think, does this go into the right direction: https://github.com/justinwoo/spago2nix/pull/21 ?

This should cover 1. and 2., but not yet 3.

[m-bock]

Well, no. Now it's impure. We have a relative path inside the generated nix file. The local packages have to be somehow put into a derivation to get around this. At least their src dir. But why the overhead of treating them differently. I'd look at them as Git repos that happen to be located inside the (mono) repo. And I also think it's ok if every revision ends up in the store as new derivation. This is also the case with your actual project sources.

After this, I think (again) the first solution is better. But I may be wrong, it's kind of tricky.

[shmish111]

@justinwoo I just came across this and was wondering what do suggest other than local packages when you have a monorepo? Currently we are using extra source directories but it seems...wrong somehow.