Allow an option to use repo instead of release archive

[guybedford]

//cc @OliverJAsh

Some sort of package.json property perhaps?

Eg:

{
  "useGitHubReleases": false
}

where the default would effectively be true?

[sheerun]

Why?

[guybedford]

Because sometimes this default isn't wanted.

[guybedford]

But it could be worth considering just drawing a line and making archives mandatory preference too.

[sheerun]

I mean: what is the difference? I'm not 100% how jspm/github works, sorry.

I thought release archives are 1:1 with repository.

[guybedford]

No - you can upload custom release archives, and also have TravisCI automatically deploy release archives from your build. This is useful for having build releases being separate to the original sources, and actually a best-practice that more people should be doing. For example, Bootstrap does this (https://github.com/twbs/bootstrap/releases).

[sheerun]

OK, so we're using different terminlogy. For me release archives are just archived tags (1:1 with source). They are available under tarball_url and zipball_url fields in API. Release asset is additional stuff that author can attach to release. Not necessary archived/built source code. It can be literally anything.

[guybedford]

Right, so we specifically detect if the first release asset is an archive, and if so use that in place of the package. Any other type of release asset is ignored.

[sheerun]

What happens if release asset is not available or doesn't contain package.json? It fallbacks to release archive? And what happens if one requests specific commit?

[guybedford]

It always first checks for a release asset that is an archive, falling back to the normal repo clone (which should should use the tarball). It takes the package.json from the original repo itself regardless though (as this is needed to ensure downloads don't block lookups). Specific-commits are not supported currently.

[trusktr]

For me release archives are just archived tags (1:1 with source).

This is what I was expecting, and also prefer.

I've been on github for quite a while now, and have been unaware of the "release asset" feature. I'm guessing it's not widely used, so the tarballs 1:1 with source would be preferable.

[trusktr]

Would "using repo instead of archive" reduce touch api.github.com? If so that would be a good default to avoid rate limit warnings.

[guybedford]

Release archives are the best practice actually. The reason it is a GitHub endpoint and not a specific Git endpoint is because the whole endpoint is tailored to the expectations of GitHub release workflows specifically.

[benib]

I'd love to be able to define a specific branch (with or without commit hash) as a dependency.

The use case is this: I have several applications that use a package with some common stuff in it. During development, this common package gets updated from time to time. I then like to push my changes in one application to the testing enviroment where everything gets build and others can review. This building needs to grab the latest code for the common package. Not being able to define a commit as dependency then forces me to tag every little change to this common package.

[guybedford]

Branches are supported.

On Friday, January 30, 2015, benib notifications@github.com wrote:

I'd love to be able to define a specific branch (with or without commit
hash) as a dependency.

The use case is this: I have several applications that use a package with
some common stuff in it. During development, this common package gets
updated from time to time. I then like to push my changes in one
application to the testing enviroment where everything gets build and
others can review. This building needs to grab the latest code for the
common package. Not being able to define a commit as dependency then forces
me to tag every little change to this common package.

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

[benib]

Ah, I see. Missed that:

jspm install github:endpoint=branchname

Cool. Thanks.

[guybedford]

From chatting with @EisenbergEffect, it could be beneficial to split the releases behaviour out into a separate endpoint:

jspm install github:twbs/bootstrap 
jspm install github-releases:twbs/bootstrap

This way, one knows upfront what one is getting and there is no hidden complexity.

In addition, the GitHub endpoint would no longer be critically dependent on API access meaning users wouldn't need to always authenticate.

Feedback welcome. Will most likely move in these directions over the next month or so.

[trusktr]

Very much 👍

[2fd]

👍

[glen-84]

👍

[glen-84]

There are at least 4 download methods:

1. Git clone (with -n and --depth 1, and maybe sparse checkout)
2. Git archive
3. GitHub raw (i.e. download from https://raw.githubusercontent.com)
4. GitHub release archive

Methods 2 & 3 should allow you to download only the necessary files and folders.

As registries:

github-clone:
github-git-archive:
github-raw:
github-release:

... seems a bit crazy. 😝

[trusktr]

@glen-84 That's a good idea! I like it. 👍

[glen-84]

The other alternative (mentioned above, to a certain extent, by Guy), is to use registry options.

{
    "registry": "github", // This already exists.
    "registryOptions": {
        "downloadMethod": "clone|gitArchive|raw|release"
    }
}

This could be overridden with "overrides".

Since all the code for the various download methods will be in one place, it may make sense to just implement two of the methods (perhaps gitArchive and release).

[trusktr]

Mmmm, yeah. An override is much better. It can be used on a per-package basis.

[letmaik]

+1 I just bumped into this, where @^x.y.z gave me the github release but @master the clone with a totally different folder structure and less files (just minified ones). I don't like using the release archives, I haven't found a need for them so far within jspm. Also, what happens when there are multiple variants of releases for each release? I just find it too brittle, so opting out, or in, would be nice.

[letmaik]

Not sure why, but suddenly I get this behaviour:

ok   Up to date - covjson-reader as github:reading-escience-centre/covjson-reader@master (0.1.1)

I request master and instead get the latest github tag (not release). I use jspm 0.16.14.

[letmaik]

Ignore my last comment. I forgot that I have to use jspm install ... to update/switch to a new dependency version. I had only edited the version manually in package.json but in config.js it still had the old one in, and this is what jspm used when installing. A bit confusing I think, especially as there is no update command like jspm update package@ver.

[trusktr]

For this reason, I personally don't check in config.js and let JSPM
generate it each time. It's good to keep it if you want to lock versions
though.

/#!/JoePea
On Dec 3, 2015 2:10 AM, "Maik Riechert" notifications@github.com wrote:

Ignore my last comment. I forgot that I have to use jspm install ... to
update/switch to a new dependency version. I had only edited the version
manually in package.json but in config.js it still had the old one in, and
this is what jspm used when installing. A bit confusing I think, especially
as there is no update command like jspm update package@ver.

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

[letmaik]

I had one particular problem with not checking in config.js (which I think makes sense). When doing a jspm init, it always used the babel transpiler even if I had traceur listed as dev dependency. @guybedford Is that a bug? Should I file an issue in jspm-cli?

[trusktr]

This default can be saved as a dotfile, so it should theoretically work.

[guybedford]

The 0.17 version entirely deprecates the release archives feature.

[erwinverdonk]

@guybedford One case for supporting hashes is when fixes are already in the master branch but not released yet (for whatever reason). I want to point to that specific fix commit and use that when installing through JSPM. It makes me less dependent on the maintainer responsible for releases.