Skip to content
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

Stack doesn't pick up new packages on hackage #227

Closed
andrewthad opened this issue Jun 9, 2015 · 13 comments
Closed

Stack doesn't pick up new packages on hackage #227

andrewthad opened this issue Jun 9, 2015 · 13 comments
Assignees
Milestone

Comments

@andrewthad
Copy link

@andrewthad andrewthad commented Jun 9, 2015

I just added cron-compat-0.2.6 to hackage (it is not on stackage), but stack keeps telling me:

The following package identifiers were not found in your indices: cron-compat-0.2.6

when I try to build. I have it listed in extra-deps, so I'm thinking that stack update must not be rebuilding the package index correctly.

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

Poking around at ~/.stack/indices/hackage.haskell.org/00-index.cache, I can see that stack definitely isn't updating this file.

Loading

@snoyberg snoyberg added this to the First stable release (0.1.0.0?) milestone Jun 9, 2015
@snoyberg snoyberg self-assigned this Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

That's a bug, it should be automatically trying to update. You can manually force it with stack update. Note that it does take up to 30 minutes for the mirrors we use to update.

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

I think the issue is with the mirrors then because I've already tried stack update. I'll probably just need to give the mirror a half hour, which isn't really a big deal. My only complaint would be that when I run stack update, stdout shows this:

Updating package index hackage.haskell.org ...

That seems a little misleading to me because the domain it shows isn't where it's actually pulling content from. If hackage.haskell.org refers to the name of the index on my computer, then I can see how that makes sense, but I feel like something like this would be better:

Updating package index hackage.haskell.org (mirrored at http://my.fakehackage.org/index/bla.tar.gz) ...

Then users would immediately understand where to look if a package was missing.

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

That's a good idea. You interested in taking a stab at making the message more useful? The relevant bit of code is:

https://github.com/commercialhaskell/stack/blob/master/src/Stack/PackageIndex.hs#L200

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

I've pushed a fix so that stack will automatically update the index when a package is missing. Leaving open for the output improvement.

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

This should work: andrewthad@341b425

I messed up the commit order by pulling upstream changes. In a few minutes, I should be able to relearn enough git to fix this and have a PR ready.

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

Got it.

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

And, to bring some closure to the original issue, it appears that the mirror has updated to include my new package.

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Awesome, thanks! Only other thing that might be worth changing is that, instead of the default index name being "hackage.haskell.org", we make it "Hackage" to make it clear that we're not using that as a URL. One minor downside is that it would force all users to have to reclone the package index next time they update, but I guess that's the cost of using beta software :)

Anyway, you have thoughts on that change?

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

I think that that would further improve clarity, so I'm for it.

Loading

@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Cool, done. I think that addresses everything, we good to close this issue?

Loading

@andrewthad
Copy link
Author

@andrewthad andrewthad commented Jun 9, 2015

Yep

Loading

@andrewthad andrewthad closed this Jun 9, 2015
@snoyberg
Copy link
Contributor

@snoyberg snoyberg commented Jun 9, 2015

Cool, thanks again!

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants