-
-
Notifications
You must be signed in to change notification settings - Fork 43
Allow an option to use repo instead of release archive #6
Comments
Why? |
Because sometimes this default isn't wanted. |
But it could be worth considering just drawing a line and making archives mandatory preference too. |
I mean: what is the difference? I'm not 100% how jspm/github works, sorry. I thought release archives are 1:1 with repository. |
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). |
OK, so we're using different terminlogy. For me release archives are just archived tags (1:1 with source). They are available under |
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. |
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? |
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. |
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. |
Would "using repo instead of archive" reduce touch api.github.com? If so that would be a good default to avoid rate limit warnings. |
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. |
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. |
Branches are supported. On Friday, January 30, 2015, benib notifications@github.com wrote:
|
Ah, I see. Missed that:
Cool. Thanks. |
From chatting with @EisenbergEffect, it could be beneficial to split the releases behaviour out into a separate endpoint:
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. |
Very much 👍 |
👍 |
👍 |
There are at least 4 download methods:
Methods 2 & 3 should allow you to download only the necessary files and folders. As registries: github-clone: ... seems a bit crazy. 😝 |
@glen-84 That's a good idea! I like it. 👍 |
The other alternative (mentioned above, to a certain extent, by Guy), is to use registry options.
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). |
Mmmm, yeah. An override is much better. It can be used on a per-package basis. |
+1 I just bumped into this, where |
Not sure why, but suddenly I get this behaviour:
I request master and instead get the latest github tag (not release). I use jspm 0.16.14. |
Ignore my last comment. I forgot that I have to use |
For this reason, I personally don't check in config.js and let JSPM /#!/JoePea
|
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? |
This default can be saved as a dotfile, so it should theoretically work. |
The 0.17 version entirely deprecates the release archives feature. |
@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. |
//cc @OliverJAsh
Some sort of package.json property perhaps?
Eg:
where the default would effectively be
true
?The text was updated successfully, but these errors were encountered: