Pathing problems with multi-file packages about melpa HOT 28 CLOSED

@purcell are you OK with the :basedir recipe parameter? I've got the rest implemented and am testing now.

from melpa.

checkout #98 and let me know what you think.

from melpa.

Closed with abbe137

from melpa.

This still doesn't work with the erlang recipe; I get the following tar contents:

 -rw-r--r--   steve/steve        88 erlang-20120418/erlang-pkg.el
 -rw-r--r--   steve/steve     18681 erlang-20120418/lib/tools/emacs/erlang-eunit.el
 -rw-r--r--   steve/steve      3682 erlang-20120418/lib/tools/emacs/erlang-flymake.el
 -rw-r--r--   steve/steve     48006 erlang-20120418/lib/tools/emacs/erlang-skels-old.el
 -rw-r--r--   steve/steve     55313 erlang-20120418/lib/tools/emacs/erlang-skels.el
 -rw-r--r--   steve/steve      3593 erlang-20120418/lib/tools/emacs/erlang-start.el
 -rw-r--r--   steve/steve    190229 erlang-20120418/lib/tools/emacs/erlang.el
 -rw-r--r--   steve/steve     45795 erlang-20120418/lib/tools/emacs/erlang_appwiz.el

The recipe looks like this:

(erlang :repo "erlang/otp"
             :fetcher github
             :files ("lib/tools/emacs/*.el"))

from melpa.

Think I got it this time.

/tmp :❯ tar xvf ~/src/melpa/packages/erlang-20111207.tar   
x erlang-20111207/erlang-pkg.el
x erlang-20111207/erlang-eunit.el
x erlang-20111207/erlang-flymake.el
x erlang-20111207/erlang-skels-old.el
x erlang-20111207/erlang-skels.el
x erlang-20111207/erlang-start.el
x erlang-20111207/erlang.el
x erlang-20111207/erlang_appwiz.el

from melpa.

It's a little messy because I am removing the prefix from the files twice: once when copying the files, and once when creating the tar. There is probably a better way to do this but I'll have to think about it.

from melpa.

Cool. BTW, try just opening .tar files in situ with emacs...

from melpa.

yes, i forget this.

from melpa.

Another random tip, while I'm at it: if you use the following code snippet, Emacs will automatically check that elisp docstrings are standards-compliant:

(require 'checkdoc)
(add-hook 'emacs-lisp-mode-hook 'checkdoc-minor-mode)

from melpa.

yes, I needed this badly.

from melpa.

OK, going to reopen. Of course I just went to add https://github.com/davidmiller/pony-mode and realized that I won't be able to package the snippets directory and the *.el files in the proper way because the elisp is in the src directory and the snippets are in their own directory. So there is no common prefix.

from melpa.

I'm thinking that before I check for prefixes, I'm first going to ignore entire directories that are in the list of files... This will fix the problem because it should always been the case that if I'm selecting individual files, then I care about the prefix, if I'm selecting entire directories then it should be getting all files starting with that parent, and the directory should be in the root of the package?

Will this be too confusing?

from melpa.

I worry slightly that we would sometimes want to select a subset of a directory's contents and preserve its path.

from melpa.

OK, so let me propose this,

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" ("snippets" t))

In this way, if you wanted to specify some files that should be ignored when figuring out the prefix you can flag them. An alternate would be to just allow :files to have a list as the last entry,

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" ("snippets"))

Or maybe a better way is to do something like,

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" ("src" . "snippets"))

Which is saying that you should assume the prefix for "snippets" is "src" but the actual path is "snippets" which would allow us more freedom.

Anyways, chime in and then I'll implement it today.

from melpa.

How about this: we iterate through :files. If the current element is a string, it is expanded and copied to the root -- this allows flattening of subdirectories, and also copying of entire subdirectories to the root.

If the current element is instead a cons cell, then its car specifies a destination subdirectory, and the cdr is expanded as above to produce one or more file sets or directories which will get copied into that subdirectory.

So in this case, the pony-mode recipe would just look like

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" "snippets"))

but if you wanted to pull just the snippets beginning with "a" into the "snippets" destination subdir, you'd write:

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" ("snippets" . "snippets/a*")))

I think that keeps the common case simple, and would eliminate the "common prefix" logic, but it might involve reviewing the existing recipes.

Make any sense?

-Steve

from melpa.

This makes sense. I need to think about it while I shower. There are a number of packages that will need to change.

This may be a minor thing but I think I would like to see this syntax allowed,

(pony-mode
 :repo "davidmiller/pony-mode"
 :fetcher github
 :files ("src/*.el" ("snippets" . ("snippets/a*" "snippets/b*"))))

So that you only need to specify the destination once for multiple files if they end up in the same directory.

The easy way to think about this is that in the initial "root" is provided, and then you can have cons cells (is that the right lingo?) that have car with the destination directory.

Then we can get rid of this prefix BS.

from melpa.

+1. I think that could also allow you to process :files recursively, because the entire :files element list would really be like one of those cons cells with an empty string for the car.

from melpa.

OK, so that took me a long time to implement. I don't know why. NOW GET IN THERE AND MAKE MY CODE LOOK BETTER!!! Although, I did use loop as mch as possible I think. Although, I kinda like having some lambdas!

a6e1dbe
ca7bf43

from melpa.

Hehe -- I'll take a look at it, but possibly not right away. :-)

from melpa.

There we go -- took ages. Check out the commit comments in 8be7c71 to see what I did.

from melpa.

Haha. I thought about this same approach but didn't see the advantage except for copying. But the way file expansion works I didn't see it hurting too badly performance wise.

from melpa.

Hey. The build right after this commit was stopping after an error. Not sure what changed that this would be happening.

from melpa.

I like that there's now one master list of (SOURCE . DEST), which can be reasoned about independently, and it keeps the consp magic out of several other functions.

from melpa.

Yep, I noticed that, which led me to fix the autopair recipe. But I also couldn't see why it didn't just log the error and continue…

-Steve

On 6 May 2012, at 13:27, Donald Ephraim Curtis wrote:

Hey. The build right after this commit was stopping after an error. Not sure what changed that this would be happening.

---

Reply to this email directly or view it on GitHub:
#97 (comment)

from melpa.

I'll check into it when I get a chance. For some reason debug-on-signal is not allowing my custom debugger to run.

from melpa.

THe problem is that the "debugger" function only gets called on the first "signal". and not all signals.

from melpa.

can we close this?

from melpa.

Yup.

from melpa.