You can clone with
HTTPS or Subversion.
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.
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?
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.
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.
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
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.
I think I got the package to work. Here is the recipe:
(emacs-dbgr :fetcher github :repo "rocky/emacs-dbgr"
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.
git clone https://github.com/milkypostman/melpa.git
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
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.
(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.)
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.
What about reallyGUD?
Really Grand Unified Debugger, also homophone for 'really good' :)
Coming up with good names is easily the hardest part about programming...
YAY! It works. So what remains is the (massive) rename. And then I get to try again.
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.
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.
The recipes for
were just merged into the melpa repository
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 :-/
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?
Sure, I'll try to handle. I'm lost though. What do I have to do?
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?
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/")))
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 ?
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.