Add this to melpa? #11

Closed
expez opened this Issue Mar 26, 2013 · 25 comments

Comments

Projects
None yet
2 participants
Contributor

expez commented Mar 26, 2013

I think it would be great if this was added to melpa. Right now it's a bit of a pain to install, especially given the dependencies. You can decide if you want to vendor the dependencies, or add them to melpa too and let the package manage install them. I think at least your testing framework would do well in Melpa.

Collaborator

rocky commented Mar 26, 2013

I'm not opposed to adding this, I just don't know how to do.

If you want to take the lead on this that would be great.

How does melpa handle dependent packages and distributions which span several files and directories?

Contributor

expez commented Mar 27, 2013

Ok. I'll take care of everything.

This means adding all the dependencies to melpa as well. I'm not sure anyone is ever going to pull loc-changes from there, but the alternative is to copy the .el file into this repository. I don't think melpa deals with git submodules. In any event it's not a huge deal. Melpa already contains 800 packages so it probably already contains a few special-interest packages. Let me know if you don't want loc-changes as a standalone package.

Contributor

expez commented Mar 27, 2013

I'll continue after you let me know what you want to do about loc-changes. It needs quite a bit of meta data before it can be published, and I don't want to waste time adding that in case you decide to just copy the file into this repository.

Collaborator

rocky commented Mar 27, 2013

Thanks for handling.

I don't want loc-changes inside emacs-dbgr since it is potentially useful outside of emacs-dbgr. For example, someone could rewrite how the compilation buffer's next-error mechanism so that it uses that. And then one could make edits to the files that the compilation buffer refers to and stale line numbers and those would then work (presumably) better.

So although it is work, I would appreciate it if you could add the meta data. Again, thanks

Contributor

expez commented Mar 27, 2013

The use of load-relative is an issue. When the packages are created all the .el files end up at the package root which is on load-path. Meaning we can freely require features without worrying about subdirectories. I'm not sure what to do about this. I'll raise an issue with the melpa guys and see if there is a way to preserve directory structure.

I'd also like your input on what entry points to this package are, so we can place an ;;;###autoload cookie above those functions so the user doesn't have to (require 'dbgr) and load everything in before it's needed.

Collaborator

rocky commented Mar 27, 2013

On Wed, Mar 27, 2013 at 9:18 AM, Lars Andersen notifications@github.comwrote:

The use of load-relative is an issue. When the packages are created all
the .el files end up at the package root which is on load-path. Meaning we
can freely require features without worrying about subdirectories. I'm not
sure what to do about this. I'll raise an issue with the melpa guys and see
if there is a way to preserve directory structure.

It would be great if you did. Traditionally emacs has been slow to even
create directories below the top-level lisp directory and Stallman resisted
that for a long time. But he's been out of the picture largely for a while

And consider a large package like cedit. It already has subdirectories like
semantic and even that has a subdirectory like analyze.

So I think hierarchical file systems are here to say and to be used.

I'd also like your input on what entry points to this package are, so we
can place an ;;;###autoload cookie above those functions so the user
doesn't have to (require 'dbgr) and load everything in before it's needed.

Ok. Will work on. Thanks for all of the help.


Reply to this email directly or view it on GitHubhttps://github.com/rocky/emacs-dbgr/issues/11#issuecomment-15522496
.

Contributor

expez commented Mar 27, 2013

I think I got the package to work. Here is the recipe:

(emacs-dbgr :fetcher github :repo "rocky/emacs-dbgr"
            :files ("dbgr.el"
            ("dbgr/common" "dbgr/common/*.el")
            ("dbgr/common/buffer" "dbgr/common/buffer/*.el")
            ("dbgr/debugger/bashdb" "dbgr/debugger/bashdb/*.el")
            ("dbgr/debugger/gdb" "dbgr/debugger/gdb/*.el")
            ("dbgr/debugger/kshdb" "dbgr/debugger/kshdb/*.el")
            ("dbgr/debugger/pdb" "dbgr/debugger/pdb/*.el")
            ("dbgr/debugger/perldb" "dbgr/debugger/perldb/*.el")
            ("dbgr/debugger/pydb" "dbgr/debugger/pydb/*.el")
            ("dbgr/debugger/pydbgr" "dbgr/debugger/pydbgr/*.el")
            ("dbgr/debugger/rdebug" "dbgr/debugger/rdebug/*.el")
            ("dbgr/debugger/remake" "dbgr/debugger/remake/*.el")
            ("dbgr/debugger/trepan" "dbgr/debugger/trepan/*.el")
            ("dbgr/debugger/trepan.pl" "dbgr/debugger/trepan.pl/*.el")
            ("dbgr/debugger/trepan3k" "dbgr/debugger/trepan3k/*.el")
            ("dbgr/debugger/trepan8" "dbgr/debugger/trepan8/*.el")
            ("dbgr/debugger/trepanx" "dbgr/debugger/trepanx/*.el")
            ("dbgr/debugger/zshdb" "dbgr/debugger/zshdb/*.el")
            ("dbgr/lang" "dbgr/lang/*.el")))

I'm hoping you want to test if the package works correctly. If so you need to run
git clone https://github.com/milkypostman/melpa.git then put that package recipe into the file melpa/recipes/emacs-dbgr and then run make recipes/emacs-dbgr. This will create melpa/packages/emacs-dbgr<version number>.tar. To test the package you can then run M-x package-install-file on that tar. It loaded just fine here, but I've never used your package (the install process was too cumbersome!) so I'm ill-suited in terms of testing.

Collaborator

rocky commented Mar 30, 2013

Ok. I've now had a chance to try this.

(I cloaned your fork in order to get load-relative and loc-changes.)

When I M-x package-install-file and give the name
.../emacs-dbgr-20130317.737.tar

I get:

package-compute-transaction: Package `change-loc-0.1.0' is unavailable

How did loc-changes get turned into change-loc?

Also, would like to drop the emacs- in the final package name.

Does:

(emacs-dbgr :fetcher github :repo "rocky/emacs-dbgr"
 ^^^^^^^^^^

cause the name to start emacs-? Better would be to come up with a better name for this project. I'm really bad at giving names as evidenced by names like "pydbgr", which Polish people complain is unpronounceable. (And if they think that, it must the so.)

Contributor

expez commented Mar 30, 2013

I have added a PR where I fixed the typo in the package declaration for emacs-dbgr. Sorry about that.

I agree that the project might benefit from a better name, but I don't have any suggestions.

Contributor

expez commented Mar 30, 2013

What about reallyGUD?
Really Grand Unified Debugger, also homophone for 'really good' :)

Coming up with good names is easily the hardest part about programming...

Collaborator

rocky commented Mar 30, 2013

Better than dbgr. So I'll go with that or the slightly shorter: realGUD.

On Sat, Mar 30, 2013 at 6:15 PM, Lars Andersen notifications@github.comwrote:

What about reallyGUD?
Really Grand Unified Debugger, also homophone for 'really good' :)

Coming up with good names is easily the hardest part about programming!


Reply to this email directly or view it on GitHubhttps://github.com/rocky/emacs-dbgr/issues/11#issuecomment-15682900
.

Collaborator

rocky commented Mar 31, 2013

YAY! It works. So what remains is the (massive) rename. And then I get to try again.

Collaborator

rocky commented Apr 1, 2013

Ok. I think everything now is about finished. I have renamed the package to realgud. The repository is still emacs-dbgr which could be a little confusing. github doesn't support a direct renaming, although I could create a new repository and delete the old one. But with that followers will have to refollow and I'll also have to change external links such as Emacs Wiki.

Is it worth the effort? What do you think?

Finally, I'm not totally happy about the loss of running the tests. Some loc-changes in fact were broken, probably in my upgrade to emacs 24.3. And indeed it looks like some code is not (anymore?) working. Even though I work on debuggers, it doesn't replace the tests and vice versa.

So I'd like to get test-simple into melpa. But since that is simple, I may try this myself after the dust settles here.

Speaking of dust settling, I expect there to be some for emacs-dbgr and emacs-loc-changes. In the back of my mind I also should rename pydbgr to something "trepani"ish. But that too is another big battle for another day.

The art of packaging things is perhaps unappreciated, but vital. So thanks again for suggesting and undertaking.

Contributor

expez commented Apr 1, 2013

I wrote a recipe for test-simple, which I will submit shortly.

As to whether or not you should rename this repo, I cannot say. You could move everything to a new one but leave a README.md directing to the next project. I'll hold off on submitting the recipe for realGUD until you've decided.

Collaborator

rocky commented Apr 1, 2013

I think for now, I'll stay with emacs-dbgr. This has been major enough to
let it sit for a little bit.

Again, thanks.

On Mon, Apr 1, 2013 at 9:52 AM, Lars Andersen notifications@github.comwrote:

I wrote a recipe for test-simple, which I will submit shortly.

As to whether or not you should rename this repo, I cannot say. You could
move everything to a new one but leave a README.md directing to the next
project. I'll hold off on submitting the recipe for realGUD until you've
decided.


Reply to this email directly or view it on GitHubhttps://github.com/rocky/emacs-dbgr/issues/11#issuecomment-15715992
.

Contributor

expez commented Apr 1, 2013

The recipes for

  • loc-changes
  • test-simple
  • load-relative
  • realGUD

were just merged into the melpa repository 👍

expez closed this Apr 1, 2013

Collaborator

rocky commented Apr 1, 2013

Can't say it enough: thank you!

Now the fun begins when people start to use this and find it as lacking as I do :-/

Contributor

expez commented Apr 1, 2013

You are quite welcome!

I thought you had merged in the proposed changes for test-simple. Now I feel silly for submitting an incompatible package to melpa. Could you take care of this?

Collaborator

rocky commented Apr 1, 2013

Sure, I'll try to handle. I'm lost though. What do I have to do?

Contributor

expez commented Apr 1, 2013

Merge this

Contributor

expez commented Apr 1, 2013

The package recipe is now live and I tried to install it from melpa:

Compiling file /home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/zshdb/zshdb.el at Mon Apr 1 21:40:22 2013
zshdb.el:4:1:Error: Cannot open load file: /home/common/helper

Compiling file /home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/trepan/init.el at Mon Apr 1 21:40:22 2013
init.el:5:1:Error: Cannot open load file: /home/common/regexp

Compiling file /home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/trepan/track-mode.el at Mon Apr 1 21:40:22 2013
track-mode.el:6:1:Error: Cannot open load file: /home/common/cmds

There's a lot more where this came from. At a glance it seems like it's unable to load a single file. Ideas?

expez reopened this Apr 1, 2013

Collaborator

rocky commented Apr 1, 2013

I'd like to be able to reproduce this so I can fix it. Right now I don't
see any of the packages except for the broken load-relative and test-unit
packages that Tom Tromey never fully installed and that he hasn't removed
although I've asked him to. Is it possible the bad load-relative from
Tromey is getting in the way?

How can force refresh on the list so I can get the error you see?

I guess checking that package-install-file is working isn't sufficient a
test when the index is updated. I'd like to understand that aspect better
so I can better check in the future.

Perhaps we can IM?

On Mon, Apr 1, 2013 at 3:46 PM, Lars Andersen notifications@github.comwrote:

The package recipe is now live and I tried to install it from melpa:

Compiling file
/home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/zshdb/zshdb.el
at Mon Apr 1 21:40:22 2013
zshdb.el:4:1:Error: Cannot open load file: /home/common/helper

Compiling file
/home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/trepan/init.el
at Mon Apr 1 21:40:22 2013
init.el:5:1:Error: Cannot open load file: /home/common/regexp

Compiling file
/home/expez/.emacs.d/elpa/realgud-20130401.5/realgud/debugger/trepan/track-mode.el
at Mon Apr 1 21:40:22 2013
track-mode.el:6:1:Error: Cannot open load file: /home/common/cmds

At a glance it seems like it's unable to load a single file. Ideas?


Reply to this email directly or view it on GitHubhttps://github.com/rocky/emacs-dbgr/issues/11#issuecomment-15733181
.

Contributor

expez commented Apr 1, 2013

I am on irc on freenode if you want to chat, but it will have to be tomorrow. Tromey isn't involed in melpa, so must likely you haven't added the melpa repository.

(setq package-archives '(("melpa" . "http://melpa.milkbox.net/packages/" )
             ("marmalade" . "http://marmalade-repo.org/packages/")
             ("gnu" . "http://elpa.gnu.org/packages/")))

expez closed this Apr 2, 2013

Collaborator

rocky commented Apr 4, 2013

Question: I've started to use cl-lib instead of cl inside emacs-dbgr to reduce compile warnings. However this of course causes problems on emacs 23. Should cl-lib be added as a dependency to realgud-pkg.el ?

Contributor

expez commented Apr 4, 2013

That will work for 24+ (24.1 and 24.2 will install, 24.3 will notice it's already installed), but I don't know about emacs 23. Better ask about this in #emacs.

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