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

feature: cabal sandbox add-source <git-repo> (darcs too ideally…) #1534

Open
kowey opened this Issue Oct 6, 2013 · 4 comments

Comments

Projects
None yet
4 participants
@kowey
Contributor

kowey commented Oct 6, 2013

One potentially useful thing for teams working with complex families of packages would be able to add source code repositories (bonus: ability to pick out branches…). This is quite helpful for synchronisation and avoids time wasted in “oh wait, that's why you're having trouble; you need to pull the lastest git version of the foo dependency from my branch” style discussions in mid-development. For me, getting somebody up and running with this new feature would consist in handing them a list of URIs for sources, and that'd be it.

Alternatives that I'm aware of so far would be to write people scripts (a bit tricky if you have Windows/Unix mixed teams) or to use something like cabal-meta instead (but preferable not to have to give people a new cmd to learn like cabal-dev)

Otherwise, the new cabal sandbox is making me happy. Thanks, devs!

@ghost ghost assigned 23Skidoo Oct 6, 2013

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Oct 6, 2013

Member

Yes, I plan to implement this at some point.

Otherwise, the new cabal sandbox is making me happy.

Glad to hear that!

Member

23Skidoo commented Oct 6, 2013

Yes, I plan to implement this at some point.

Otherwise, the new cabal sandbox is making me happy.

Glad to hear that!

@23Skidoo

This comment has been minimized.

Show comment
Hide comment
@23Skidoo

23Skidoo Dec 9, 2013

Member

I'm starting to think that it's better to fix this by implementing #1367 and using svn:externals or git submodules for external packages in your tree.

Member

23Skidoo commented Dec 9, 2013

I'm starting to think that it's better to fix this by implementing #1367 and using svn:externals or git submodules for external packages in your tree.

@AndrewRademacher

This comment has been minimized.

Show comment
Hide comment
@AndrewRademacher

AndrewRademacher Apr 10, 2014

This would also be valuable when you need to make updates to someone else's public repo. When you fork, fix and then submit a pull request, it would be great to be able to just point cabal at your fork so that you can keep working on your project. Then, when/if the package maintainer accepts the pull and updates Hackage revert to using it as a primary source.

AndrewRademacher commented Apr 10, 2014

This would also be valuable when you need to make updates to someone else's public repo. When you fork, fix and then submit a pull request, it would be great to be able to just point cabal at your fork so that you can keep working on your project. Then, when/if the package maintainer accepts the pull and updates Hackage revert to using it as a primary source.

@mietek

This comment has been minimized.

Show comment
Hide comment
@mietek

mietek Nov 11, 2014

Contributor

Halcyon supports declaring sandbox sources with the HALCYON_SANDBOX_SOURCES option.

See Try Haskell for an example of declaring the git HEAD version of mueval as a sandbox source.

Contributor

mietek commented Nov 11, 2014

Halcyon supports declaring sandbox sources with the HALCYON_SANDBOX_SOURCES option.

See Try Haskell for an example of declaring the git HEAD version of mueval as a sandbox source.

@23Skidoo 23Skidoo removed their assignment Jul 27, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment