chexxor [5:17 PM]
Is there an existing recent discussion thread about moving to a psc-package dependency resolver from bower for PS core libs?
I recall there was discussion about a desire to do that when psc-package becomes more mature, and I’m curious what the latest on that discussion is. (edited)
natefaubion [5:19 PM]
I don’t know of one.
chexxor [5:21 PM]
Does such a package manager need to be “general purpose”? To reference dependencies from other package managers, for example.
before it’s adopted by PS core libs, I mean.
I believe Bower doesn’t do that kind of thing, so it shouldn’t be required of psc-package. (edited)
package sets are pretty nice - they inspire so much more confidence in me than Bower and its dynamic resolving
natefaubion [5:23 PM]
The only reason why something isn’t done in the core libs is because it’s a lot of effort and nobody has made an attempt to get it to work
The reasons are rarely philosophical
doing such a thing for core libs would probably mean making a package set for core libs that they can use
chexxor [5:25 PM]
Ok. I was thinking about how to improve newcomer experience for a 1.0 release of PS, and I come back to thinking it might be a good reason/a good time to move off of bower.
natefaubion [5:25 PM]
depending only on psc-package however makes changes hard, frankly
psc-package itself is missing core features that make that easy, which bower includes, but I don’t think we want to depend on things like spago in core, which make it easier
chexxor [5:25 PM]
I meant a package-sets based solution, not specifically psc-package.
oh interesting
natefaubion [5:27 PM]
psc-package is great when you are building an app
lack of a bower link equivalent makes in progress changes hard though
and no, manually symlinking is not a solution
or at least, it’s not one that anyone wants to put up with
I would like to be proven wrong though, and that requires someone to make an attempt
So no, there are no core contributors planning to move everything over to psc-package
however, if someone wants to make an attempt at setting that up, or automating it, it would likely be appreciated.
In general, there are no hidden plans or agendas anywhere
so asking “what is core planning” doesn’t usually lead to an answer
because it’s usually “they aren’t”
justinw [5:31 PM]
psc package for library development… doesn’t work 
chexxor [5:32 PM]
It’s interesting, because moving to it would philosophically be saying that a PureScript library can’t specify exact versions of its dependencies, which is… weird…
justinw [5:32 PM]
just the problem with things based on sets, you’re going to have to deal with the awkward in-transition sets
natefaubion [5:33 PM]
it basically means you have to build an interim set for every closer of dependencies (edited)
chexxor [5:33 PM]
I guess that wouldn’t change if the set was defined as a Dhall expression, which is “extensible”
natefaubion [5:34 PM]
it does as long as you can define ad-hoc dependencies
but requiring something to be in a git repo somewhere, and pointing to a specific commit… doesn’t work
for in progress library changes
so it’s true that tooling has somewhat solved those issues
but I don’t think that core should use experimental tooling that augments core
which means that there is probably a solution that would need to be moved into core
however, core using bower does not prevent anyone from doing anything
so there is no compelling reason to move, unless bower just stops working (edited)
justinw [5:36 PM]
btw i have a solution for using bower packages and bower anything with package sets, but ofc it doesn’t work on windows and is only for nix perverts
bower seems to complain that there are non-bower deps but otherwise everything works
also i clicked on that bower.json and had to look up what that library was again
natefaubion [5:37 PM]
there are recent discussions about npm allowing you to require a single install of libs, which would also be an alternative
chexxor [5:44 PM]
Do you think it’s ok to cross-post this thread to the discourse? I just want the replies to be findable by me again, and I guess it might be useful to others too. Otherwise I can just put it in my personal memos.
I ask because dependency managers are a bit of a… they can led to heated discussion. 
natefaubion [5:46 PM]
I think the answer is, we don’t want to adopt a solution that requires us to put in more work to update stuff
if it’s possible to update everything at least as conveniently as bower, then we would move to it
nobody loves bower in particular, it’s just convenient and we don’t have to maintain it (edited)
hdgarrood [5:50 PM]
My only strong opinion on this is that I don’t want to do away with bounds entirely
Package sets are great, cf atackage
Stackage
natefaubion [5:51 PM]
I don’t think bounds would affect anything in core
maybe for a community, sure
hdgarrood [5:51 PM]
But once your ecosystem reaches a certain size you basically need them
Right
chexxor [5:51 PM]
Could use package-sets for introduction material, though, right? That might be the only thing needed for a mitigated major release
hdgarrood [5:51 PM]
Like imagine trying to maintain stackage without version bounds info
natefaubion [5:52 PM]
I have no idea what process they use. Do they use version bounds?
I thought they just had huge CI infrastructure
hdgarrood [5:52 PM]
Yes
I’m not a big fan of switching to psc package for intro material but I don’t remember exactly why right now
There’s some discussion on an issue on the docs repo
What is a ‘mitigated major release’
natefaubion [5:56 PM]
I’m not fundamentally against psc-package for intro, but the biggest problem is there’s no convenient answer to “what do I do when there’s something I want that isn’t in the set”
chexxor [5:56 PM]
Whatever pain people felt and complained about in the 0.12 release
hdgarrood [5:57 PM]
Ohh I see
natefaubion [5:57 PM]
for something like the book, a package-set is perfect though
hdgarrood [5:57 PM]
True
natefaubion [5:57 PM]
and is way better than bower for ensuring that it still works
I don’t have a big opinion on version bounds. I’m happy with just overrides pointing to a commit to get moving, but that’s just me
psc-package doesn’t have that though
chexxor [5:59 PM]
Yeah, I would only consider a Dhall-based package set definition, personally.
natefaubion [5:59 PM]
there is no answer to the “what do I do when…”
except try to upstream changes, make your own git repo, etc, which is all soul-crushing
chexxor [6:00 PM]
There’s a relatively straightforward way to modify a remote package set in your local project if it’s a Dhall expression.
natefaubion [6:00 PM]
sure, but that’s not psc-package
that’s external tooling applying workarounds for psc-package’s sake
it requires extra steps that you have to remember to invoke, eg
so it’s just hard to say “yeah, recommend that for everyone”
personally, I wouldn’t hesitate to say that psc-package should support dhall in a first class way
chexxor [6:02 PM]
it could be psc-package. In my mind, psc-package is the idea of using package-sets and an implementation of that idea. I think it doesn’t matter if the package-set format used by psc-package changes.
natefaubion [6:02 PM]
it does matter as far as introductory material though
since you have to have it all installed
chexxor [6:03 PM]
It matters that a package-set is encoded as dhall expression? (edited)
natefaubion [6:03 PM]
No it matters how you invoke and use it
chexxor [6:04 PM]
Ah, yeah, I see. Good thing Dhall is a Haskell lib and psc-package is a Haskell app. 
Could just install the one thing.
I realize I’m talking about could-bes here (edited)
Relevant discussion for the idea of native Dhall in psc-package ^
afk, food