[ELPA] New package: GNU Hyperbole 6.0

[ELPA] New package: GNU Hyperbole 6.0

[Mats Lidell]

Hi,

I'm the maintainer of GNU Hyperbole together with its original author Bob
Weiner. Active development of the package has started again thanks to Bob
putting in lot of time and energy in the project.  We would now like the soon
upcoming release to be added to ELPA.

This is a short description of what Hyperbole is. (Top of the HY-ABOUT file
included below.)
----------------------------------------------------------------------
GNU Hyperbole (pronounced Ga-new Hi-per-bo-lee), or just Hyperbole, is
an open, efficient, and programmable hypertextual information
management and hypertext system implemented as a GNU Emacs package.
It works well on GNU Emacs 24.3 or above.

It includes easy-to-use, powerful hypertextual button types without
the need to learn a markup language; a hierarchical, record-based
contact manager; a rapid window and frame control system; and a
powerful multi-level auto-numbered outliner.  All features are aimed
at making textual information management and display fast and easy.

Hyperbole allows hypertext buttons to be embedded within unstructured
and structured files, mail messages and news articles.  It offers
intuitive keyboard and mouse-based control of information display
within multiple windows.  It also provides point-and-click access to
World-Wide Web URLs, Info manuals, ftp archives, etc.

The Hyperbole wiki page, "https://www.emacswiki.org/emacs/Hyperbole",
explains the many ways it differs from and is complementary to Org mode.

[...]
----------------------------------------------------------------------

The package has been maintained at

    https://savannah.gnu.org/projects/hyperbole/

There is more info about the package there but that has not been updated yet
with the latest release. This is partly due to questions about what the best
way is to do the packaging and if that puts requirements on where and how to
maintain it.

The plan now is to continue to maintain it at savannah and include it in ELPA
as a subtree. The package is rather big so we think it would be wise to keep
the daily development outside of ELPA and only sync when doing releases.

What do you think? I that the right approach?

Since we don't have push rights to the ELPA repository we would need that. Or
for a speedier handling maybe someone with those rights already can help us,
if only initially, to get the first release out?

The technical details - that the package follows the right conventions etc is
best inspected when we have it uploaded to the repo at savannah I think. Could
that be an acceptable plan? 

Yours Mats

Re: [ELPA] New package: GNU Hyperbole 6.0

[John Wiegley]

>>>>> "ML" == Mats Lidell <mats.lidell@cag.se> writes:

ML> I'm the maintainer of GNU Hyperbole together with its original author Bob
ML> Weiner. Active development of the package has started again thanks to Bob
ML> putting in lot of time and energy in the project. We would now like the
ML> soon upcoming release to be added to ELPA.

Hi Mats,

I don't see a download for 6.0 in your Downloads Area at Savannah.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

Re: [ELPA] New package: GNU Hyperbole 6.0

[Robert Weiner]

I will put it there as soon as I can.  We have been using a semi-hidden archive location during development.  If you go back to the last release announcement, it is there and easily downloadable over the web.

-- Bob

> On Jul 15, 2016, at 7:59 PM, John Wiegley <jwiegley@gmail.com> wrote:
> 
> I don't see a download for 6.0 in your Downloads Area at Savannah.

Re: [ELPA] New package: GNU Hyperbole 6.0

[Stefan Monnier]

> The package has been maintained at
>
>     https://savannah.gnu.org/projects/hyperbole/
>
> There is more info about the package there but that has not been updated yet
> with the latest release. This is partly due to questions about what the best
> way is to do the packaging and if that puts requirements on where and how to
> maintain it.

> The plan now is to continue to maintain it at savannah and include it in ELPA
> as a subtree.  The package is rather big so we think it would be wise to keep
> the daily development outside of ELPA and only sync when doing releases.

If you haven't read elpa.git's README, I recommend you do that first.
I usually prefer packages be installed as subtrees, but in the case of
large packages like this one, it makes more sense to install it as an
"external" which is more like a submodule (it's actually just
a separate branch in the same repository).

You could maintain it directly from the elpa.git repository, or you can
have the upstream in https://savannah.gnu.org/projects/hyperbole and so
regular syncs every once in a while.

> Since we don't have push rights to the ELPA repository we would need that.

That's easy to arrange.  Request membership in the "emacs" group from
your Savannah page.

> The technical details - that the package follows the right conventions
> etc is best inspected when we have it uploaded to the repo at savannah
> I think.

Right.  The Git repository is empty and the Hg repository seems to only
go up to 2013, so I can't give an opinion on the current code.
I'll just assume the general shape hasn't changed much.  Any reason why
the real code is still not in there?

One of the main limitations of ELPA is that it doesn't really like Elisp
files other than in the root directory.  If I look at the Hg repository,
all Elisp files except for the kotl/*.el are in the root dir, so it
looks OK (and it'd be easy to move those kotl/* files to the root).


        Stefan

Re: [ELPA] New package: GNU Hyperbole 6.0

[Robert Weiner]

[-- Attachment #1: Type: text/plain, Size: 1883 bytes --]

On Fri, Jul 15, 2016 at 11:39 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

>
> I usually prefer packages be installed as subtrees, but in the case of
> large packages like this one, it makes more sense to install it as an
> "external" which is more like a submodule (it's actually just
> a separate branch in the same repository).
>

​Ok, we'll look at that.  We really just want the easiest approach where
multiple people can contribute and it is easy to push releases to ELPA.​


>
> > Since we don't have push rights to the ELPA repository we would need
> that.
>
> That's easy to arrange.  Request membership in the "emacs" group from
> your Savannah page.
>

​Thanks for the pointer, Stefan.  This has now been done.
We also submitted for rights to upload to ftp.gnu.org.
​

> Right.  The Git repository is empty and the Hg repository seems to only
> go up to 2013, so I can't give an opinion on the current code.
> I'll just assume the general shape hasn't changed much.  Any reason why
> the real code is still not in there?
>

​We are just now going to create the Git repository so we start with a
modern codebase.
In the meantime, you can inspect the latest release at:
www.plasmas.biz/rswe/hyperbole-6.0.tar
I have digitally signed that release as well (so JohnW you could work with
it).​

One of the main limitations of ELPA is that it doesn't really like Elisp
> files other than in the root directory.  If I look at the Hg repository,
> all Elisp files except for the kotl/*.el are in the root dir, so it
> looks OK (and it'd be easy to move those kotl/* files to the root).
>

​This is silly in 2016; packages should be able to have multiple
subdirectories of code as many real-world software packages do.  Step by
step, we'll get there.

Cheers,

Bob
​


>
>
>         Stefan
>
>
>

[-- Attachment #2: Type: text/html, Size: 4430 bytes --]

Re: [ELPA] New package: GNU Hyperbole 6.0

[Stefan Monnier]

> ​This is silly in 2016; packages should be able to have multiple
> subdirectories of code as many real-world software packages do.
> Step by step, we'll get there.

Elisp packages are typically fairly small, so complex structures are
usually overkill.  Bigger packages generally benefit from being split
into various smaller ones.

So I'm not convinced it's silly, even tho I won't claim it's a feature.


        Stefan

Re: [ELPA] New package: GNU Hyperbole 6.0

[Mats Lidell]

> Stefan Monnier writes:
>
> If you haven't read elpa.git's README, I recommend you do that first.

I have read it but it suggests that if you don't know which of subtree or
external to use you should go for subtree. :-) So the easy solution was to
assume that subtree would be the thing for us but ask the list for advice
which we got. I'll read up on external now when I know it is the preferred way
for large packages like this.

> You could maintain it directly from the elpa.git repository, or you can
> have the upstream in https://savannah.gnu.org/projects/hyperbole and so
> regular syncs every once in a while.

The latter sounded better to me to keep the scope more local for our work.

> That's easy to arrange.  Request membership in the "emacs" group from
> your Savannah page.

I'm happy that you suggest that. It's done.

> Right.  The Git repository is empty and the Hg repository seems to only
> go up to 2013, so I can't give an opinion on the current code.

We are switching from hg to git and start from a little different code base
than was used before. So that is why git is empty. It will be populated if we
choose to maintain it at savannah.

My plan was that if the way of working with maintaining at savannah and using
a subtree (or more likely now external) was good we would start by populating
the git repo with version 6.0 and you could then have a look at it.

But as Bob has written in another reply it is available over the net so maybe
you could inspect it there to give us more feedback?

> I'll just assume the general shape hasn't changed much.  Any reason why
> the real code is still not in there?

No it is roughly the same and it has been maintained elsewhere since we
started from a slightly different code base.

> One of the main limitations of ELPA is that it doesn't really like Elisp
> files other than in the root directory.

OK. Thanks for the pointer. We will look into that.

Yours
-- 
%% Mats

Re: [ELPA] New package: GNU Hyperbole 6.0

[Robert Weiner]

On Sat, Jul 16, 2016 at 11:11 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
> Elisp packages are typically fairly small, so complex structures are
> usually overkill.  Bigger packages generally benefit from being split
> into various smaller ones.

I see two sides to this.  If you create a large package with multiple
subsystems all connected through a single user interface, you could
split it into a master package with separate packages for the
subsystems upon which the master depends.  This increases modularity
and potentially allows application of the subsystems with different
UIs.  But the costs are fairly high: increased version management
complexity, separation of the UI from the subsystems, more work for
the maintainers and increased documentation difficulty.  Given that
virtually all Emacs work is on a volunteer basis, keeping the author
and maintainer complexity at reasonable levels to encourage further
work should be a significant concern.

XEmacs separated out a lot of packages from its core but then offered
a sumo tarball with everything included as one option.  I bet the sumo
option was a very popular download because users want easy installs
and a good set of features each time they commit time to work with a
piece of software and will typically choose this over modularity.  So
if users like integration and it reduces author complexity, that is
one reason to favor it.  Internally, things can still be modular and
then programmers can utilize the modules as they like.

Just my thoughts.

Bob

Re: [ELPA] New package: GNU Hyperbole 6.0

[Stefan Monnier]

>> You could maintain it directly from the elpa.git repository, or you can
>> have the upstream in https://savannah.gnu.org/projects/hyperbole and so
>> regular syncs every once in a while.
> The latter sounded better to me to keep the scope more local for our work.

That's perfectly fine, at least as long as you do regular syncs between
the two (if you don't do them often enough, the syncs become a lot more
strenuous).

> But as Bob has written in another reply it is available over the net so maybe
> you could inspect it there to give us more feedback?

Nowadays I find it much too painful to read code without its VCS
metadata, so I only do it when I have no other choice.  In the case of
Hyperbole I can just wait (and in the mean time keep wondering why on
earth you don't make the repository available somehow somewhere).


        Stefan

Re: [ELPA] New package: GNU Hyperbole 6.0

[Robert Weiner]

There is a detailed ChangeLog and no other history so even when it us in git there won't be anything more, so why wait?

-- Bob

> On Jul 16, 2016, at 9:46 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 
> Nowadays I find it much too painful to read code without its VCS
> metadata, so I only do it when I have no other choice.

Re: [ELPA] New package: GNU Hyperbole 6.0

[Stefan Monnier]

> XEmacs separated out a lot of packages from its core but then offered
> a sumo tarball with everything included as one option.

The fact the ELPA likes the Elisp files to all be at top-level doesn't
mean we couldn't have a sumo-like thingy on top.

Actually "git pull .../elpa.git; make externals; make" followed by
adding the relevant dir to package-directory-list gives you already
something very similar.

> So if users like integration and it reduces author complexity, that is
> one reason to favor it.  Internally, things can still be modular and
> then programmers can utilize the modules as they like.

Exactly.


        Stefan

Re: [ELPA] New package: GNU Hyperbole 6.0

[Stefan Monnier]

> There is a detailed ChangeLog and no other history so even when it us in git
> there won't be anything more, so why wait?

Because I can.


        Stefan "who never reads Elisp without changing it along the way"


>> On Jul 16, 2016, at 9:46 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> 
>> Nowadays I find it much too painful to read code without its VCS
>> metadata, so I only do it when I have no other choice.