-
Notifications
You must be signed in to change notification settings - Fork 44
Removed feature: implement add to package set from bower #77
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
|
||
addFromBower :: String -> IO () | ||
addFromBower name = do | ||
let bowerProc = inproc "bower" [ "info", T.pack name, "--json", "-l=error" ] empty |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good as a first pass, but that we'd want to either emulate the bits of Bower that we need, or make it more obvious that having bower installed as a dependency is a requirement for this feature.
(My personal preference is doing the emulating; as far as I can tell, that means pulling down the JSON registry blob and then looking through it for the package, but fortunately not much else.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't want to reimplement anything from Bower personally. I doubt parsing the registry would be anywhere near as fast as using a user's existing Bower setup and all.
Could be better documented that you need Bower though, yeah.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The registry is super simple - it's just a case of hitting a URL like http://bower.herokuapp.com/packages/purescript-halogen, the registry doesn't actually contain any of the information about the package though, so it means fetching the bower.json
from the location the registry returns after that... which is less simple. 😉
I don't love the idea of depending on bower either, but I understand not wanting to reimplement half of it too, so, just thought I'd throw that info in. I did quite a bit of work around this stuff for my bower-replacement-but-still-using-the-registry project that hasn't seen the light of day yet.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, the old registry URL is deprecated, so it would be better to use this format: https://registry.bower.io/packages/purescript-halogen
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Uh yes, I actually meant to use that one, must have copied it from some old code and just didn't look at it 😄
The code I linked in the corresponding issue gets all the versions by looking at the tags and then downloads the Even still I don't think that should go into psc-package itself, I'd rather put it in a separate binary. Maybe alongside the package-set repo? |
@kritzcreek you did say that it pretty quickly requires a Github auth token? Which seems like more of an annoyance. I don't see the point of having this be separate from psc-package though. By being in the main executable, you can very easily see that it's a possible option -- otherwise, people will have to search around forever to find out that this exists. |
f001958
to
7be8342
Compare
addFromBower :: String -> IO () | ||
addFromBower name = do | ||
let bowerProc = inproc "bower" [ "info", T.pack name, "--json", "-l=error" ] empty | ||
result <- fold <$> shellToIOText bowerProc |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Instead of shelling out to bower
, you could let the user run the info
command and pipe it in here. We already try to use some of the Bower JSON formats in purs publish
for example, so I think this approach makes sense here too.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But in the end the user wants what happens here right? I wouldn't like to have to look up how to awkwardly use this, and at best, many users would be copy pasting an example command to their terminal and changing it.
I think this approach does make sense actually - what we are doing here is specific to bower, so I think it makes sense to shell out to bower rather than expecting some JSON to be supplied on standard input; it doesn’t really make sense to do what the proposed ‘add-from-bower’ command would do but with some other tool instead of bower. I also think it makes sense to put this code in here rather than in a separate executable, as it doesn’t add any noticeable amount of bloat or anything like that: people would still be able to do everything psc-package does currently with no problems if they didn’t have bower installed. However the alternative, as Justin pointed out, is most likely that people who might be able to benefit from this either have to perform an extra install step, or never even learn that this exists. |
What kind of error do you get if |
It looks like this:
if anyone has a good idea on how to make this more obvious and easier to work with im all ears |
Should we merge this? Seems like the error message wouldn't be even bad for technical users. |
7be8342
to
18af423
Compare
* Updates for 0.11.5 * Use smolder v8.0.0 for now * Use smolder-v7.0.0 * Remove pux * Update packages.json
This (mis)feature was never used for managing projects using psc-package. It was only used to do some hacky management of package sets.
fixes #76