Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Fixing the specific version of a package locally #136

Closed
dudebout opened this Issue · 57 comments

4 participants

Nicolas Dudebout Johan Andersson Grant Rettke Steve Purcell
Nicolas Dudebout

I have an issue related to #132. I install most of my packages from melpa but have a few that I install directly from git. For example, until today I kept my own version of cask to not have the bootstrap problem.

It would be nice if from the Cask file I could say something something along the lines (depends-local "cask" "<my-path-to-cask>"). I would not want cask to have to deal with git and/or versions, just a cleaner way to put all my sources in the file.

Johan Andersson
Owner

I have been thinking about something like this for a while. In my Emacs configuration I have a submodule with my yasnippets, which I obviously don't want. Somewhat the point of Cask is to remove submodules. But at the same time I don't want to publish it to Melpa as a package. In this case I probably could have done that because there are quite a few people using it. But I know other people that for example have their own color theme, which they definitely don't want to push to Melpa.

A "depends-local" would not solve these issues perfectly, because I still have to keep the files in my repo. Either as submodules or as a vendor file.

I don't know what the best solution would be, but here's another solution that we can discus around:

(source melpa)

(depends-on "yasnippet")
(depends-on "yasnippets" :git "https://github.com/rejeep/yasnippets")
;; or
(depends-on "yasnippets" :url "https://github.com/rejeep/yasnippets/archive/master.zip"))

If we used Melpa's package-build.el, this would be quite simple to achieve.

Nicolas Dudebout

I like this proposal a lot. The use cases you gave really resonate with me.

Johan Andersson
Owner

That solution would also go hand in hand with Melpa stable releases. Stable is fine in most cases, but sometimes you want bleeding edge.

Grant Rettke

From what you guys shared in #132 this is a nice solution.

Johan Andersson rejeep referenced this issue in milkypostman/melpa
Closed

Package build #1274

Johan Andersson
Owner

FYI. The Melpa guys added a few public functions to package-build.el, so we are now able to implement this. It will be a part of version 0.6 (see https://github.com/cask/cask/tree/v0.6-wip).

Grant Rettke
Johan Andersson
Owner

This has been implemented in the v0.6-wip branch. Would be great if you tried it out.

Johan Andersson rejeep closed this
Nicolas Dudebout
Nicolas Dudebout
Johan Andersson
Owner

That's most likely because you have an older commander version. Try latest Cask again and then run cask upgrade, which will update Cask's dependencies.

Nicolas Dudebout
Johan Andersson
Owner

You have to use the git url => https://github.com/magit/magit.git

Johan Andersson
Owner

No support for branches yet, but that would be easy to add.

Nicolas Dudebout
Johan Andersson
Owner

There is no :url property. I'm using package-build.el to do all the download and packaging magic. So if we would like to support that, we would have to implement it in package-build.el.

The supported fetchers are: https://github.com/cask/cask/blob/v0.6-wip/cask.el#L173-L175

Nicolas Dudebout
Johan Andersson
Owner

I see. It makes no sense that both Cask and Melpa implements this functionality, so eventually package-build.el will be extracted from Melpa.

Nicolas Dudebout
Johan Andersson
Owner

Ok, this is new code that I haven't tested out myself very much. Will try it out locally.

Nicolas Dudebout
Johan Andersson
Owner

This is related to package-build.el, I've reported a bug. See milkypostman/melpa#1463

Johan Andersson rejeep reopened this
Johan Andersson rejeep closed this
Johan Andersson
Owner

I've made some updated that should fix this. This for example works for me. You?

(source melpa)

(depends-on "magit" :git "https://github.com/magit/magit.git")
Johan Andersson
Owner

FYI, use cask upgrade-cask to fetch the new version.

Nicolas Dudebout
Johan Andersson
Owner

With the latest version you can now also specify ref, for example:

(source melpa)

(depends-on "magit" :git "https://github.com/magit/magit.git" :ref "origin/next")
Nicolas Dudebout
Johan Andersson
Owner

The prefix "origin/" is weird.

Yes, but for some reason package-build.el fails when not specifying origin. Not sure why?

Nicolas Dudebout
Johan Andersson
Owner

Well, it would be hard (possible?) for Cask to know for sure if it's safe to add it.

Nicolas Dudebout
Johan Andersson
Owner

You are probably right. I guess there will never be any other remote that origin. But we still have to cover the case where the user includes origin himself.

I'm no Git expert, but I guess origin/SHA work just as well?

Nicolas Dudebout
Johan Andersson
Owner

The user should not include origin as this is not part of the ref.

You are right!

So this is actually more of a package-build bug. We could solve this by simply prepending the ref with origin/. But if package-build fixes the issue it will break.

//cc @purcell What are your thoughts?

Nicolas Dudebout
Steve Purcell

Yeah, since we're normally cloning a full repo from the remote in order to build it, we explicitly use the name origin.

Not sure if it's relevant to this discussion, but we do support a :commit option, which can be used to check out specific branches or versions. Only a couple of our recipes actually use it.

Johan Andersson
Owner

Cask is using :commit, but it requires the origin/ prefix it seems.

Steve Purcell

Hmm, yeah, I guess it would. We call git reset --hard with the value of :commit, and the remote branch refs will all be prefixed with the remote name. I guess we could add a :ref option, as an alternative to :commit, and automatically prepend "origin/" to it...

Steve Purcell

The recipes we have which are using :commit look like this:

elnode:4:2: :commit "origin/melpa"
elpy:4:2: :commit "origin/release"
insfactor:3:12:           :commit "origin/release")
starter-kit:2:14:             :commit "origin/v2")
starter-kit-bindings:3:23:                      :commit "origin/v2"
starter-kit-eshell:3:21:                    :commit "origin/v2"
starter-kit-js:3:17:                :commit "origin/v2"
starter-kit-lisp:3:19:                  :commit "origin/v2"
starter-kit-perl:3:19:                  :commit "origin/v2"
starter-kit-ruby:3:19:                  :commit "origin/v2"

so :ref or :branch would clean those up a bit.

Johan Andersson
Owner

I guess we could add a :ref option, as an alternative to :commit, and automatically prepend "origin/" to it...

Either package-build does it or Cask does it. My vote is one package-build.

Nicolas Dudebout
Nicolas Dudebout
Steve Purcell

Makes sense. We'll do that, but probably tomorrow at this point: I'll ping you back when done, to let you know whether :ref or :branch is the one to use. :-)

Johan Andersson
Owner

We'll do that, but probably tomorrow at this point:

Do it when you have a chance, no rush!

If we follow how Ruby Bundler does it, we should allow this in Cask:

(depends-on "magit" "https://github.com/magit/magit.git" :ref => "4aded")
(depends-on "magit" "https://github.com/magit/magit.git" :branch => "2-3-stable")
(depends-on "magit" "https://github.com/magit/magit.git" :tag => "v2.3.5")
Johan Andersson
Owner

Does anyone know the difference between all these concepts? What is the difference between a ref and a commit for example?

Nicolas Dudebout
Johan Andersson
Owner

I think it makes sense to follow how Bundler does it, but I have no idea what the difference between a ref and a commit is.

Nicolas Dudebout
Johan Andersson
Owner

Ok!

I would like Cask to follow the Bundler style with ref, branch and tag without ever having to prepend with origin/. I'm not completely sure what needs to be done in package-build for that to happen.

@purcell We have only talked about Git so far, but I guess this change would affect the other VCS's as well?

Nicolas Dudebout
Johan Andersson
Owner

We could have a single tag, for the sake of argument "commit" that does it all.

That would be nice!

as long as it is unambiguous I will get the right behavior

If I remember correctly, when I didn't specify origin/, I got an error saying it was not unambiguous. But that only happened when I used it from Cask. When I entered that directory and ran the same Git command, it worked just fine.

Steve Purcell purcell referenced this issue from a commit in milkypostman/melpa
Steve Purcell purcell Provide :branch for git recipes 56116eb
Steve Purcell

@dudebout No, that won't work. Look:

% git clone git@github.com:technomancy/emacs-starter-kit.git
Cloning into 'emacs-starter-kit'...
remote: Reusing existing pack: 2439, done.
remote: Counting objects: 100, done.
remote: Compressing objects: 100% (97/97), done.
remote: Total 2539 (delta 3), reused 100 (delta 3)
Receiving objects: 100% (2539/2539), 4.25 MiB | 1.39 MiB/s, done.
Resolving deltas: 100% (1092/1092), done.
Checking connectivity... done.
% cd ./emacs-starter-kit                                                                                   /tmp 20:33
% git reset --hard v2
fatal: ambiguous argument 'v2': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

but

% git reset --hard origin/v2
HEAD is now at e372360 Merge pull request #161 from apella/v2

Anyway, I've added a :branch option now, which I think is the right way to go.

Nicolas Dudebout
Steve Purcell

We used git checkout in the past, but it's not the right way to do things in this case. We keep the clones of upstream repositories for successive builds, and sometimes those repos receive force-pushes after we have cloned them. Dealing with synchronising local branches with remote branches that have been force-pushed is complicated. The git reset method is extremely simple in comparison, and has worked extremely well for us.

Nicolas Dudebout
Johan Andersson
Owner

@purcell What if you want to use a specific commit sha?

Steve Purcell

What if you want to use a specific commit sha?

Just use :commit in that case.

Johan Andersson
Owner

Awesome!

Vlad Piersec caisah referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Bozhidar Batsov bbatsov referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.