vis 0.2

[terhorst]

• Have you followed the guidelines in our Contributing document?
• Have you checked to ensure there aren't other open Pull Requests for the same formula update/change?
• Does your submission pass brew audit --strict --online <formula> (where <formula> is the name of the formula you're submitting)?
• Have you built your formula locally prior to submission with brew install <formula>?

[tduzan-te]

Was just about to build one myself. This looks pretty clean. Very interested in trying this out on OS X but I prefer all my packages to be managed through brew. Any ETA on this being merged?

[apjanke]

How about an ETA of "now"? Does "now" work for you? :)

Merged. Thank you for your contribution to Homebrew!

For future reference, please squash your commits to one commit per formula when you end up doing edits to a PR. (I squashed them while doing the merge this time.)

[apjanke]

Closed by 4b0765d

[tduzan-te]

Thank you 👍

[DomT4]

Sorry, in hindsight this wasn't quite ready to merge.

Primarily the cause is that this tool conflicts with the system-supplied vis which is a different tool entirely, and can lead to significant confusion if something else calls vis expecting one thing and ends up with a text editor instead. We will either need to rename the conflicting utility or make this keg_only; you'll probably find the former preferable in terms of usability.

I actually already fell over this personally trying to write a better test here and wondering why the viz from the command-line and the viz in the formula test were behaving entirely differently.

The other issue is that the test doesn't fit our style. I understand there's a limited amount you can do with a text editor but even if we stick to the same limited theme it should have been:

test do
  assert_match version.to_s, shell_output("#{bin}/vis -v 2>&1", 1)
end

Or similar.

[apjanke]

That was my fault. I jumped the gun on merging even though I had seen the conflicting vis. Sorry for the inconvenience!

[terhorst]

Fixed testing. I tentatively suggest renaming to vise or vis-editor; I chose the shorter one.

[apjanke]

I like vise too. Short enough to use on CLI, and close to original name. And there's no other vise AFAIK. (There's VISE Installer, but that has little chance of being a common Unix command or being in Homebrew.)

Maybe it's worth asking the upstream vis developer their opinion? If they're supporting OS X, they're going to (or have already) run in to this too. Best if their whole user base uses the same alt name, and we like to defer to upstream anyway.

In addition to vis, this package installs some vis-* helper commands, and a vis man page. I think these should also be correspondingly renamed. (And maybe the man page contents munged.) Sometimes build scripts support binary_name or prefix/suffix options to support renames (like we do with gnu utilities). Look around for one of those, which would be better than doing individual renames in formula code.

Actually—this could affect self-calls, scripting, and process detection, too. vi is an interactive, scriptable, nontrivial program. We should really do some research and ask upstream about this before just renaming a couple binaries.

Sorry, looks like ETA is going to be a bit further out than I originally thought.

[terhorst]

Seems like the developer is aware of the conflict and prefers to stay the course (martanne/vis#101). Understandable I suppose. Probably the best option is keg-only then.

[kfihihc]

It seems this PR has been revert, what happen?
Will it be merged again?

[terhorst]

Made it keg-only. This led to an additional problem with vis being unable to locate its startup scripts, necessitating the creation of a shim to set the environment.

[MikeMcQuaid]

If there's a wrapper script you could perhaps just make libexec the prefix, add the wrapper script and not make it keg-only?

[terhorst]

Okay, that seems to work. Still no working man page but oh well.

[twe4ked]

Not sure about renaming the package. How about only linking if the user chooses to?

[tdsmith]

That's essentially what keg-only is; I think it's a pretty lousy user experience if you just want your editor to work.

If the author(s) has/have strong feelings about renaming the binary, we'll respect that but probably also decline to distribute the software. If that ends up being the case, someone could elect to maintain their own tap for the formula. The linked document has some advice and we'd be happy to field questions.

@martanne, do you have a preference?

[martanne]

Disclaimer: I know almost nothing about homebrew/Mac OS X.

I think renaming the binary is the wrong thing to do. I thought users would be able to chose/override the vis binary with brew link --force vis? What is the purpose of "keg-only" formulas if you do not want to distribute those?

Also the old formula by @twe4ked explicitly added a dependency on lpeg which is necessary for syntax highlighting. The current approach however seems to omit it? This will likely result in users complaining directly to upstream i.e. me.

The user experience of homebrew could probably be improved by properly handling Lua dependencies ...

[terhorst]

I wasn't aware that Homebrew could enforce external package dependencies. Formula updated. I'm not inclined to manage a tap for this, so if that is the consensus and someone reading this feels like doing so, feel free.

[tdsmith]

What is the purpose of "keg-only" formulas if you do not want to distribute those?

Mostly they are libraries which are dependencies of other things which Homebrew distributes. Few of them are applications.

I wasn't aware that Homebrew could enforce external package dependencies.

We don't allow it in core; we prefer that formulas download and install modules like this to a private prefix and arrange to make them available when the executables are invoked. In the Python world, jrnl is an example of this in Homebrew.

The user experience of homebrew could probably be improved by properly handling Lua dependencies...

This is certainly true and we would love to work with an interested contributor who understands the Lua ecosystem well; we do not have any at present.

[tdsmith]

Thanks for your efforts, @terhorst!

[martanne]

Renaming to vise doesn't make much sense, how about vis-editor as was done by the NetBSD/pkgsrc maintainer. I expect users to be able to configure a shell alias or symlink to make it available under their preferred name.

If you want to follow the NetBSD package, the changes required would be:

• rename vis.1 manual page to vis-editor.1
• rename vis-open to vis-editor-open and patching vis-cmds.c
• rename vis-clipboard to vis-editor-clipboard and patching register.c

whether the last two points are necessary is up to you I guess. I could also introduce some #defines to make the names of these binaries easily override able at compile time.

The LPeg dependency should be handled in one form or another.

[apjanke]

Yeah, let's go with vis-editor and user aliases if you like that and a big packager is already using that name. Consistency is a win here, and we like to defer to upstream whenever possible. Shell aliases or functions for user preferred names are really low-risk; most dev environments will ignore them.

Renaming vis-open and vis-clipboard to vis-editor-* sounds like a good idea to me, to preserve the general <program>-<subtool> prefix naming pattern. But not necessary.

Adding some #defines (or a ./configure option?) would be great: easier to write the formula to use them, and then it's clear that a name transformation is to some extent supported, and we're not just going off on our own here.

[martanne]

I added two #defines which can be specified/overridden at compile time. This should make the renaming easier.

[MikeMcQuaid]

Great thanks @martanne. Adding these as a patch and reopening might be a good option?

[terhorst]

I have updated the formula to take advantage of these #defines. It is HEAD only until a new version is issued which incorporates these patches. @martanne If you could issue a release 0.2.1 (or something) that I can point to in the formula then I think we'd be done.

[soveran]

@terhorst Just a heads up to tell you that version 0.3 was tagged a few days ago.

[esdf]

@terhorst @martanne I have updated this formula to build version 0.4.

I ran into a problem with the configure script - it seems that if termkey is available then the configure script assumes ncursesw is also present. I "fixed" that by removing the reference to ncursesw from the configure script (but perhaps ncursesw should be added as a dependency instead?).

The script is updated to satisfy brew audit --strict --online vis, and it builds, installs and runs correctly for me via brew install vis

class Vis < Formula
  desc "Vim-like text editor"
  homepage "https://github.com/martanne/vis"
  url "https://github.com/martanne/vis/archive/v0.4.tar.gz"
  sha256 "f11ba41cfb86dd39475960abfd12469de4da0ccfdb941f1d7680d89d987694c5"
  head "https://github.com/martanne/vis.git"

  depends_on "lua" => :build
  depends_on "libtermkey"

  resource "lpeg" do
    url "https://luarocks.org/manifests/gvvaughan/lpeg-1.0.1-1.src.rock", :using => :nounzip
    sha256 "149be31e0155c4694f77ea7264d9b398dd134eca0d00ff03358d91a6cfb2ea9d"
  end

  def script; <<-EOS.undent
    #!/bin/sh
    VIS_BASE=`brew --prefix vis`/libexec
    VIS_PATH=$VIS_BASE/share/vis $VIS_BASE/bin/vis $@
    EOS
  end

  def install
    luapath = libexec/"vendor"
    ENV["LUA_PATH"] = "#{luapath}/share/lua/5.2/?.lua"
    ENV["LUA_CPATH"] = "#{luapath}/lib/lua/5.2/?.so"

    resources.each do |r|
      r.stage do
        system "luarocks", "build", r.name, "--tree=#{luapath}"
      end
    end

    # avoid inclusion of -lncursesw alongside -ltermkey because lncursesw might not exist (also avoid use of lncursesw altogether to simplify things)
    inreplace "configure" do |s|
      s.gsub!("for libcurses in ncursesw ncurses libcurses; do", "for libcurses in ncurses libcurses; do")
      s.gsub!("LDFLAGS_TERMKEY=\"-ltermkey -lncursesw\"", "LDFLAGS_TERMKEY=\"-ltermkey\"")
    end

    system "./configure", "--prefix=#{libexec}"
    system "make", "install"
    (bin/"vise").write script
  end

  def caveats; <<-EOS.undent
    To avoid a name conflict with the OS X system utility /usr/bin/vis,
    this text editor must be invoked by calling `vise` ("vis-editor").
  EOS
  end

  test do
    assert_match version.to_s, shell_output("#{bin}/vise -v 2>&1", 1)
  end
end

[DomT4]

it seems that if termkey is available then the configure script assumes ncursesw is also present.

The incorrect nature of that assumption should be reported & ideally fixed upstream, but essentially if you have a working formula it's better to file a new PR with that instead of bumping old threads. It's easier for ILZ et al. to review things that way rather than hoping they spot the new comment.

[esdf]

@DomT4 Yes, I understand. I was hoping to get some feedback. I have created the appropriate PR #21215