Fixing the specific version of a package locally #136

Closed
dudebout opened this Issue Oct 23, 2013 · 57 comments

Projects

None yet

4 participants

Contributor

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.

Owner
rejeep commented Oct 23, 2013

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.

Contributor

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

Owner
rejeep commented Oct 23, 2013

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

grettke commented Oct 24, 2013

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

@rejeep rejeep referenced this issue in melpa/melpa Dec 28, 2013
Closed

Package build #1274

Owner
rejeep commented Jan 5, 2014

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).

grettke commented Jan 6, 2014

Excellent, thanks for letting us know Johan.

On Sun, Jan 5, 2014 at 9:33 AM, Johan Andersson notifications@github.comwrote:

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).


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-31606835
.

Grant Rettke | ACM, AMA, COG, IEEE
grettke@acm.org | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson

Owner
rejeep commented Feb 1, 2014

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

@rejeep rejeep closed this Feb 1, 2014
Contributor
dudebout commented Feb 3, 2014

Since I updated cask, everytime I call `cask" I get: Wrong number of
arguments: nil, 3

On Sat, Feb 1, 2014 at 9:35 AM, Johan Andersson notifications@github.comwrote:

Closed #136 #136.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136
.

Contributor
dudebout commented Feb 3, 2014

Going back to v0.5.1 fixes it.

On Sun, Feb 2, 2014 at 9:20 PM, Nicolas Dudebout <nicolas.dudebout@gmail.com

wrote:

Since I updated cask, everytime I call `cask" I get: Wrong number of
arguments: nil, 3

On Sat, Feb 1, 2014 at 9:35 AM, Johan Andersson notifications@github.comwrote:

Closed #136 #136.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136
.

Owner
rejeep commented Feb 3, 2014

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.

Contributor
dudebout commented Feb 3, 2014

This was the case indeed.

I tried to put the following two things in my Cask file and got errors each
time:

On Mon, Feb 3, 2014 at 1:43 AM, Johan Andersson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-33927935
.

Owner
rejeep commented Feb 3, 2014

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

Owner
rejeep commented Feb 3, 2014

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

Contributor
dudebout commented Feb 3, 2014

OK. I'll try that tonight. What other options/combinations would you like
me to try? A :url? What else?

On Mon, Feb 3, 2014 at 7:44 AM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-33950784
.

Owner
rejeep commented Feb 3, 2014

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

Contributor
dudebout commented Feb 3, 2014

OK. I did not know where to look. I was using your first message in this
thread as a reference.

On Mon, Feb 3, 2014 at 8:26 AM, Johan Andersson notifications@github.comwrote:

There is no :url property. I'm using package-build.elhttps://github.com/milkypostman/melpa/blob/master/package-build.elto 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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-33953716
.

Owner
rejeep commented Feb 3, 2014

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

Contributor
dudebout commented Feb 4, 2014

Using the git-url gave me the same error message of "no such file or
directory"

On Mon, Feb 3, 2014 at 8:31 AM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-33954024
.

Owner
rejeep commented Feb 4, 2014

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

Contributor
dudebout commented Feb 4, 2014

Let me know whenever you want me to make some other tests.

On Tue, Feb 4, 2014 at 9:22 AM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34063093
.

Owner
rejeep commented Feb 4, 2014

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

@rejeep rejeep reopened this Feb 4, 2014
@rejeep rejeep closed this Feb 4, 2014
Owner
rejeep commented Feb 5, 2014

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")
Owner
rejeep commented Feb 5, 2014

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

Contributor
dudebout commented Feb 5, 2014

It seems to work for me.

On Wed, Feb 5, 2014 at 1:55 PM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34223976
.

Owner
rejeep commented Feb 6, 2014

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")
Contributor
dudebout commented Feb 6, 2014

Sweet.

The prefix "origin/" is weird. Since all the git stuff is done in the
background, it might be better to just call the ref "next".

On Thu, Feb 6, 2014 at 3:02 AM, Johan Andersson notifications@github.comwrote:

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")


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34300333
.

Owner
rejeep commented Feb 6, 2014

The prefix "origin/" is weird.

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

Contributor
dudebout commented Feb 6, 2014

Under the hood there needs to be an "origin/". I was suggesting that Cask
prepends it automatically.

On Thu, Feb 6, 2014 at 8:44 AM, Johan Andersson notifications@github.comwrote:

The prefix "origin/" is weird.

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34323634
.

Owner
rejeep commented Feb 6, 2014

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

Contributor
dudebout commented Feb 6, 2014

If I understand correctly, Cask passes the git url and the ref to
package-build.el.
Since there is no other argument, package-build.el is going to do a git
clone which will have as a consequence to set the git url as the origin
remote. Therefore the ref could only be referring to the origin remote.

Am I missing one of your concerns?

On Thu, Feb 6, 2014 at 8:53 AM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34324292
.

Owner
rejeep commented Feb 6, 2014

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?

Contributor
dudebout commented Feb 6, 2014

The user should not include origin as this is not part of the ref. The
user having to use origin is a leaky abstraction. In essence, the user
must understand that package-build.el under the hood checks out under the
origin remote.

I double checked and origin/SHA does not work in git. This is normal, as
the SHA is independent of the remote.

I understand that these two comments each push for a different course of
action. I should look into package-build.el one of these days to
understand what they are doing.

On Thu, Feb 6, 2014 at 9:03 AM, Johan Andersson notifications@github.comwrote:

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 originhimself.

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34325188
.

Owner
rejeep commented Feb 6, 2014

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?

Contributor
dudebout commented Feb 6, 2014

I agree that prepending "origin/" is not really good. git automatically
infers what you mean and offers ways to disambiguate. If package-build.el
passes this string to git, this should be possible to use this feature of
git.

On Thu, Feb 6, 2014 at 9:29 AM, Johan Andersson notifications@github.comwrote:

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-buildbug. We could solve this by
simply prepending therefwithorigin/`. But if package-build fixes the
issue it will break.

//cc @purcell https://github.com/purcell What are your thoughts?


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34327436
.

purcell commented Feb 6, 2014

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.

Owner
rejeep commented Feb 6, 2014

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

purcell commented Feb 6, 2014

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...

purcell commented Feb 6, 2014

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.

Owner
rejeep commented Feb 6, 2014

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.

Contributor
dudebout commented Feb 6, 2014

A form such as :branch "master" transformed automatically in
"origin/master" would be very clean.
It could coexist with the current :commit "origin/master" that gives the
full power of git when needed.

On Thu, Feb 6, 2014 at 2:27 PM, Steve Purcell notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34360556
.

Contributor
dudebout commented Feb 6, 2014

It seems more appropriate for package-build to do as Cask does not touch
git at all.

On Thu, Feb 6, 2014 at 2:29 PM, Johan Andersson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34360753
.

purcell commented Feb 6, 2014

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. :-)

Owner
rejeep commented Feb 6, 2014

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")
Owner
rejeep commented Feb 6, 2014

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

Contributor
dudebout commented Feb 6, 2014

What exactly do you want to know?

On Thu, Feb 6, 2014 at 2:37 PM, Johan Andersson notifications@github.comwrote:

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34361695
.

Owner
rejeep commented Feb 6, 2014

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.

Contributor
dudebout commented Feb 6, 2014

I think what ruby bundler calls a ref is called a commit in git lingo.

refs in git encompass all the name translations done for remotes,
branches and tags (see .git/refs/)

On Thu, Feb 6, 2014 at 2:46 PM, Johan Andersson notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34362661
.

Owner
rejeep commented Feb 6, 2014

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?

Contributor
dudebout commented Feb 6, 2014

@purcell, why is there a need to prepend with "origin/" in the first place.
When using git I can use a sha, a local branch, a remote branch or a tag
and as long as it is unambiguous I will get the right behavior.
We could have a single tag, for the sake of argument "commit" that does it
all.

On Thu, Feb 6, 2014 at 3:11 PM, Johan Andersson notifications@github.comwrote:

Ok!

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

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


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34365255
.

Owner
rejeep commented Feb 6, 2014

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.

@purcell purcell added a commit to melpa/melpa that referenced this issue Feb 6, 2014
@purcell purcell Provide :branch for git recipes 56116eb
purcell commented Feb 6, 2014

@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.

Contributor
dudebout commented Feb 6, 2014

Why using git reset instead of git checkout?

On Thu, Feb 6, 2014 at 3:36 PM, Steve Purcell notifications@github.comwrote:

@dudebout https://github.com/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 [...] -- [...]'

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34367900
.

purcell commented Feb 6, 2014

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.

Contributor
dudebout commented Feb 6, 2014

OK. I might look into why checkout and reset work differently.

On Thu, Feb 6, 2014 at 5:38 PM, Steve Purcell notifications@github.comwrote:

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.


Reply to this email directly or view it on GitHubhttps://github.com/cask/cask/issues/136#issuecomment-34382933
.

Owner
rejeep commented Feb 7, 2014

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

purcell commented Feb 7, 2014

What if you want to use a specific commit sha?

Just use :commit in that case.

Owner
rejeep commented Feb 7, 2014

Awesome!

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