You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add command to install all packages in the set #607
Having a command that did this would make it easier to update the ecosystem when we having breaking PS releases. Another option would be to document what to execute to get the same effect.
Since I don't know Bash as well as I probably should, I found that this worked after I looked into this more:
sudo apt-get install xclip -y
spago ls packages > example.txt && cat example.txt | sed -r "s/([a-zA-Z0-9-]+).*/\1/"| tr '\n'''| xclip -selection c
spago install <CTRL+SHIFT+V>
I was thinking about this a bit more; since Dhall is supposed to be programmable, why not just derive the packages key as the full set of packages in the set?
I got pretty close with this:
let packages = ./packages.dhall
let Package = { dependencies : List Text, repo : Text, version : Text }
let PackageAssoc = { mapKey : Text, mapValue : Package }
let getPackageName = \(v : PackageAssoc) -> v.mapKey
let List/map = https://prelude.dhall-lang.org/List/map
in
{ name = "core"
, dependencies =
List/map PackageAssoc Text getPackageName (toMap packages)
, packages = packages
, sources = [ "src/**/*.purs" ]
}
but unfortunately this results in:
[info] Generating new hashes for the package set file so it will be cached.. (this might take some time)
[error] The following packages do not exist in your package set:
[error] - metadata
and there does not appear to be any way of filtering the metadata package out of the list, because Dhall deliberately does not provide a string equality operation; its philosophy is that you should be avoiding stringly-typed programming (dhall-lang/dhall-lang#164).
I'd agree with the solution from @hdgarrood - the reason why that's not working with the current master is that we're excluding (for no reason IMO) the metadata package from the set. With the patch in #609 everything works as intended 😄
P.S.: well, the whole metadata package thing is a giant hack and it's due to keeping backwards compatibility with the package set format over time. I hope we'll be able to fix this with the new registry. I'm working on this too
Now that #610 is in, I'll pivot this issue towards documenting in the README the pure-Dhall solution proposed by Harry - I'd like a new section called "Install all the packages in the set"
I forgot to post this here previously: even after #610, I was still running into problems with the fancy Dhall approach. I don't recognise the error you are getting, so I'm not sure if it's the same one or if I just forgot what it looked like. I ended up deciding the Dhall approach was too clever and I reverted back to
@f-f yes, as I mentioned above. I've only tried it with the monorepo setup but I don't know why it would be any different.
I also inlined List/map for convenience because at the time I didn't want to deal with satisfying Nix that it wasn't going to change out from under me.
Activity
hdgarrood commentedon Apr 11, 2020
I think this does the job, and is a little more straightforward:
hdgarrood commentedon Apr 11, 2020
I was thinking about this a bit more; since Dhall is supposed to be programmable, why not just derive the
packageskey as the full set of packages in the set?I got pretty close with this:
but unfortunately this results in:
and there does not appear to be any way of filtering the
metadatapackage out of the list, because Dhall deliberately does not provide a string equality operation; its philosophy is that you should be avoiding stringly-typed programming (dhall-lang/dhall-lang#164).f-f commentedon Apr 12, 2020
I'd agree with the solution from @hdgarrood - the reason why that's not working with the current
masteris that we're excluding (for no reason IMO) themetadatapackage from the set. With the patch in #609 everything works as intended 😄P.S.: well, the whole
metadatapackage thing is a giant hack and it's due to keeping backwards compatibility with the package set format over time. I hope we'll be able to fix this with the new registry. I'm working on this toof-f commentedon Apr 14, 2020
Now that #610 is in, I'll pivot this issue towards documenting in the README the pure-Dhall solution proposed by Harry - I'd like a new section called "Install all the packages in the set"
paulyoung commentedon Jul 22, 2020
I just tried using the suggested
spago.dhallfile with the monorepo setup and got this:I'm not sure if I can look into this now but I'm wondering if it's due to a Dhall or prelude version mismatch.
paulyoung commentedon Jul 22, 2020
It seems probable that this is the cause #594
hdgarrood commentedon Jul 22, 2020
I forgot to post this here previously: even after #610, I was still running into problems with the fancy Dhall approach. I don't recognise the error you are getting, so I'm not sure if it's the same one or if I just forgot what it looked like. I ended up deciding the Dhall approach was too clever and I reverted back to
which works, although you do need to rerun it each time you update your package set.
paulyoung commentedon Jul 22, 2020
Using
Locationinstead ofPackagefor the type ofmapValueworks for me.f-f commentedon Jul 22, 2020
@paulyoung you mean that the Dhall snippet in the README is incorrect in the case of a monorepo and that you have found a fix?
paulyoung commentedon Aug 13, 2020
@f-f yes, as I mentioned above. I've only tried it with the monorepo setup but I don't know why it would be any different.
I also inlined
List/mapfor convenience because at the time I didn't want to deal with satisfying Nix that it wasn't going to change out from under me.