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

Provide proxy to latest binary release #532

Closed
3noch opened this issue Jul 6, 2015 · 14 comments
Closed

Provide proxy to latest binary release #532

3noch opened this issue Jul 6, 2015 · 14 comments

Comments

@3noch
Copy link
Member

3noch commented Jul 6, 2015

GitHub makes it very hard (if not impossible) to provide a download link for the latest release of a file.

Would it makes sense to host a proxying URL that allows script writers to always have access to the latest binary release of stack? Even stack upgrade could use it potentially. But I imagine the primary benefit would be for "bootstrapping" scripts or provisioning tools to simply download the latest binary and put it on the PATH.

Since stack takes you the rest of the way, it would be possible to provide a shell script and a PowerShell script and reach almost every OS on the planet. By copying from those templates, users could make their systems run with potentially zero system dependencies. That would be awesome.

@phadej
Copy link
Collaborator

phadej commented Jul 6, 2015

For bootstrapping scripts latest version is dangerous concept, especially when back-incompatible changes are introduced.

Which got me thinking, does stack download the latest GHC in major series (i.e. will download 7.10.2 when it comes out for say nightly-2015-07-06 resolver), or are snapshots tied to exact GHC version?

@phadej
Copy link
Collaborator

phadej commented Jul 6, 2015

And by the way, starting from stack-0.1.2.0 you can add stack upgrade to the bootstrap script: done.

@3noch
Copy link
Member Author

3noch commented Jul 6, 2015

@phadej Good idea. I'm pretty sure the "danger" is highly related to what features you need. I sure hope that bootstrapping to the latest in order to run stack build is not dangerous! But I see your point.

@DanBurton
Copy link
Contributor

does stack download the latest GHC in major series?

Yes. Snapshots are associated with a GHC major series, not with a precise
GHC version. Pinging @snoyberg to double check that this is still the case.

On Monday, July 6, 2015, Elliot Cameron [email protected] wrote:

@phadej https://github.com/phadej Good idea. I'm pretty sure the
"danger" is highly related to what features you need. I sure hope that
bootstrapping to the latest in order to run stack build is not dangerous!
But I see your point.


Reply to this email directly or view it on GitHub
#532 (comment)
.

-- Dan Burton

@phadej
Copy link
Collaborator

phadej commented Jul 6, 2015

@3noch to clarify myself. I think it's a bad idea that there are time-dependent variables in CI / provision etc scripts. Something that worked yesterday may stop working tomorrow: introduced regression; accidental exploiting of a bug, fixed later. The latter is not the case for stack build, but that should work with older version too.

OTOH, I'm 👍 for making process of installing stack (and thus Haskell system) on new machine "time-invariant" and easy. There are repositories for ubuntu and fedora, we could generate slack.pkg for mac (i can investigate that), and installer for windows.

@borsboom
Copy link
Contributor

borsboom commented Jul 6, 2015

... we could generate stack.pkg for mac ...

We currently use FPM to generate .debs and .rpms. It supposedly supports generating OS X .pkgs as well, although I've never tried it.

@3noch
Copy link
Member Author

3noch commented Jul 6, 2015

@phadej @manny-fp Very nice. I'm on Windows, which makes bootstrapping annoyingly hard. Installers are nice, but not automatic. The closest I can come to currently is a PowerShell script that downloads stack into some known bin folder on the PATH.

@borsboom
Copy link
Contributor

borsboom commented Jul 6, 2015

This shell incantation finds the latest x86_64-linux release:

curl -sSL https://api.github.com/repos/commercialhaskell/stack/releases/latest \
    |grep '"browser_download_url": ".*/stack-[0-9\.]\+-x86_64-linux.gz"' \
    |sed 's/.*"\(.*\)"$/\1/'

My Windows batch file scripting skills are rusty, but I imagine something similar must be possible using PowerShell.

@3noch
Copy link
Member Author

3noch commented Jul 6, 2015

@manny-fp Yes...sigh. I'm sure it is. 😉

@borsboom
Copy link
Contributor

borsboom commented Jul 6, 2015

I think once a real stack website is up having it provide friendlier download URLs is something it should do. Pinging @chrisdone who I believe has the web site on his plate.

@snoyberg snoyberg modified the milestone: 0.3.0.0 Jul 13, 2015
@borsboom
Copy link
Contributor

borsboom commented Oct 3, 2015

Assigned to @chrisdone so this gets included with the web site.

@snoyberg snoyberg assigned snoyberg and unassigned chrisdone Oct 15, 2015
snoyberg added a commit to commercialhaskell/stackage-content that referenced this issue Oct 15, 2015
@snoyberg
Copy link
Contributor

This is now implemented on stackage.org. You can see the list of available downloads at:

https://www.stackage.org/stack

Linux 64-bit, for example, is at:

https://www.stackage.org/stack/linux-x86_64

The list of available names is controlled by:

https://github.com/fpco/stackage-content/blob/master/stack/releases.yaml

@borsboom
Copy link
Contributor

Cool, thanks! A thought: we could make this page the primary location we send people to download the latest bindists (instead of the latest Github release). I think all it would need is a link to https://github.com/commercialhaskell/stack/blob/release/doc/install_and_upgrade.md for instructions, and a link to https://github.com/commercialhaskell/stack/releases for release notes and older versions. That would make these handy "always latest" more discoverable.

@borsboom
Copy link
Contributor

Never mind my last thought, that's would be the backwards way to go about it. Instead I updated the installation instructions to point to the new platform-specific URLs directly (rather than at the latest Github release).

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

No branches or pull requests

6 participants