[proposal] - Use plus mark to represent -forge for installing pkg

I want:
>> pkg install +database
to represent:
>> pkg install -forge database

Is this okay? I may add some code in pkg.

is there a particularly good reason for wanting that shorthand? currently using - more closely follows the general convention of most unix-like programmatic options.

you are of course welcome to make whatever changes you want locally or to your own clone of octave, but I’m not sure how likely it will be for such a proposed change to be adopted for the actual code.

maybe that can be done via an alias of some kind in .octaverc? someone more familiar with such things may have better thoughts there.

There are plus-mark-style designs in modern softwares.

For example,

$ git push origin +master

has a similar meaning to

$ git push origin master --force

And .octaverc cannot control this kind of usage. I should add some logic in pkg whereabout nargin().

I don’t see the need for this change.

1 Like

The most important meaning of this change is, -forge is a very common installation param, so it deserves an easier misc form.

IIUC, the community is moving away from Octave Forge step by step. The path forward when it comes to distributing packages for Octave seems to be a more flexible package index:

Given that, you’ll probably see less and less of -forge.

@siko1056 is working on an improved pkg function:

I don’t know if it will have a shorthand for packages from that index. But it might be more fruitful to work on that instead.

It would make sense to omit the -forge option, since packages are moving (slowly) away from Sourceforge but what is the purpose of the + symbol.
IMO, it would be more appropriate to just type

pkg install database


pkg install database image statistics

for installing multiple packages at once.

Btw, I noticed that -forge option in 7.2 can also install packages that are only indexed at GNU Octave - Packages, which is very cool :+1:. I personally don’t mind the -forge option, but it might be just a matter of habit of installing packages in this manner for years.

For multiple index, my understand is pkg automatically update all indexes when installing with -forge option, then download with/without specific verison of tarball.

The -forge is an online install option, maybe pkg need an -online option to disconfuse that -forge is not only about OctaveForge. The Github index works fine with -forge too.

Yes, another thing is, pkg install without -forge means offline installation., but pkg install -forge means online installation. This’s different from the intuition.

Thanks for pointing that out. I wasn’t aware of that (or forgot about it).
Tangentially related to this, I pushed a change to show the download URL(s) for pkg install -forge -verbose:
octave: 776446acdc7b (gnu.org)

1 Like

IMO this is a matter of perspective. AFAIK -forge intuitively declares an online source. Personally I am quite happy with its current capability and @mmuetzel 's latest addition improves the clarity of what and how pkg is doing when installing from online sources.

I also added the plus mark feature, but when I
$ hg push
, it gives an error like
abort: HTTP Error 403: ssl required.

I wonder how you solved this hg push problem?

Only maintainers can push to the repository.
Please, propose changes on the bug (or patch) tracker on savannah (ideally in the form of mercurial patches): bugs.octave.org
See also: Developer FAQ - Octave

plus_mark_pkg_feature.patch (2.6 KB)

I made a patch of this feature. Please review the code.

Given that @jwe already wrote that he doesn’t think we need this feature, I don’t know if it is much worth pursuing it.
But still some general feedback (without having tested it):

  • If I understand your proposed change correctly, it replaces a + in front of any argument by -forge and the rest of that argument. That essentially means that all packages that are listed will be downloaded from remote. Is this what a user would expect when they wrote pkg install package1 +package2? They might expect that only package2 will be downloaded from remote…
    The current implementation with a separate -forge argument makes it clearer that it applies to everything imho.
  • What about input like pkg +-verbose? Should that really be allowed?
  • The loop over the input arguments might check arguments multiple times.
  • The code converts forth and back between cell arrays and comma-separated lists where it doesn’t need to.
  • Do we need a separate loop for this? Couldn’t that be part of the existing loop that parses the input arguments?

The -forge option has been around for quite some time and every user is used to it when downloading from online sources. Most likely, a lot of users just use the -forge option to automatically download the package they need from the internet without specific knowledge where the package’s repo is located. And in many cases, they might not really care about it.

Changing the semantics of a critical function like pkg is not a light decision to take, since all users are affected from such a change. Regarding online sources, the extra packages may be slowly migrating to Github and the Octave Packages Index may be hosted there at the moment, but this might change in the future. So is it is much more convenient for the users to keep the -forge syntax unaltered and redirect or add extra sources that are indexing packages, rather than altering a long-standing syntax that everybody is used to and it already works like a charm.

I really haven’t understood yet what’s the extra benefits from the syntax notation you are proposing.
These are just my thoughts of course. It is up to the core developers to make such a decision.

“I don’t see the car is moving.” doesn’t mean “I don’t think the car is moving.”. Maybe you have a different understand to his reply.

  • pkg install package1 +package2 (pkg install package1 -forge package2)
  • The current implementation with a separate -forge argument makes it clearer that it applies to everything imho.
    This is about the switch-case logic. I just regard this as a feature, not a bug.
  • What about input like pkg +-verbose(pkg install -forge -verbose)? Should that really be allowed?
    That’s reasonable. I didn’t forbid this in the new code. Furthermore, I can add more forbidden rules into the code if needed.
  • The loop over the input arguments might check arguments multiple times.
    That’s true. Every plus-mark-style param should be transformed.
  • The code converts forth and back between cell arrays and comma-separated lists where it doesn’t need to.
    Maybe there’s better code style. Since Octave doesn’t support inserting element into comma-separated lists, I cannot avoid this kind of tranformation.
  • Do we need a separate loop for this? Couldn’t that be part of the existing loop that parses the input arguments?
    Since the varargin should change, it’s better designing a separated loop to preprocess specific for varargin. Think about if there will be more alias designs, and we have a separate loop, we can preprocess in the same separate loop. But if we just add new loop logic into the original loop, the code of the new features will test more cases.

I didn’t get what you mean by that…

Never doubted that. But does it really need to strip the + mark multiple times from the same argument?

The following pattern doesn’t need to convert the original cell array to a comma-separated list:

a = {1, 2, 3};
b = [a(1:2), {4}, a(3)];

Why does varargin need to change at all? IIUC, you only want to set octave_forge to true if the first character matches +. That could easily be done in the “main” input parsing loop…

Edit: Having written all that. I’m agreeing with @jwe that we don’t need that feature.
Maybe, we might want to have an alias for the -forge argument (while keeping the original argument around). But I find the current implementation (with the + that applies to everything not just to the package where it is added) kind of confusing for a user.
I won’t oppose if someone thinks this should be added. But I probably won’t push it myself…

just noting that there was a bit of prior discussion on aliasing the -forge option name now that it no longer strictly points to Octave Forge.

There is also much discussion on the new package repository and an in-development new pkg tool at


Something that might be more useful than introducing a syntax shorthand for one function would be to provide more sophisticated command line completion.

For programs, it doesn’t really matter whether you are writing -forge PKG or +PKG because it’s easy to enter repetitive text with a good editor.

For interactive command line usage, it would help if typing the TAB character after pkg listed all relevant completions available at that point. If we had that, then I don’t really see that there is a significant difference between pkg -forge PKG and pkg +PKG (at least for the effort required to enter the command).

Providing multiple ways to do the same thing may seem like a nice thing do to, but I think the additional complexity of the implementation is not worth the small convenience. And I’m not sure that it is really convenient. If I see pkg +PKG I’m not sure what that means. But if I see pkg -forge PKG or pkg -download PKG, I can probably guess what that means.