Sniprun AUR package

[lmartinez-mirror]

Hi, I'm currently writing up several PKGBUILDs of sniprun for submitting into the AUR. One of the things Arch Linux has in their guidelines for Rust packages is using a Cargo.lock file for compiling.

It would be great to have an up-to-date Cargo.lock file in the current and future releases for this.

[michaelb]

Sure, i guess some dependencies are not quite up to date in there.

I'll try to keep them up to date manually, since i guess that "*" dependencies are so-so and that there is not way to automate that like the pkgver.....but if there is a way, i'll take it :-).

Maybe a github bot? Or maybe "*" dependencies in cargo.toml are ok, and then updating the lock is only one 'cargo update' away? You tell me

I also use Arch and i have a few packages up there myself

I think what need some attention is the (new) issue with neovim 0.4.x vs 0.5 stuff.
The install.sh script is basically patchwork, with different failsafes etc... but the important compatibility stuff lies in "neovim < 0.5 needs sniprun < 0.5"

[michaelb]

God i'm so ashamed of this script

[lmartinez-mirror]

If it means anything, I don't use the install.sh for the PKGBUILD, opting to place things manually with install. Regarding the compatibility issues, I'd have to create a separate PKGBUILD for those using neovim stable. It shouldn't be too much of a hassle.

As for the Cargo.lock, do what is easiest for you. I don't have the slightest clue about Rust and their file trees.

[michaelb]

Since i won't be publishing a crate, I went with the easy solution: "*" dependencies (meaning i'll fetch latest at each cargo update which will then put fixed version in the Cargo.lock).

The Cargo.lock file is now checked-in with git and up to date, i'll keep cargo-updating at each release.

[lmartinez-mirror]

This is what I have thus far. It's a split package because the vim and Rust components come from the same upstream.

# Maintainer: lmartinez-mirror
pkgname=('sniprun' 'neovim-sniprun')
pkgver=0.5.2
pkgrel=1
pkgdesc='A neovim plugin to independently run snippets of code'
arch=('x86_64')
url="https://github.com/michaelb/sniprun"
license=('MIT')
makedepends=('cargo' 'gcc-libs')
source=("$pkgname-$pkgver.tar.gz::$url/archive/refs/tags/v$pkgver.tar.gz")
sha256sums=('97d952f54235cf5b52553cafbb9466b2f83dbc1c562279b9ce940dfc308a00c7')

build() {
  cd "$pkgname-$pkgver"
  cargo build --release --all-features --target-dir=target
}

# check() {
#   cd "$pkgname-$pkgver"
#   cargo test --release --locked --target-dir=target
# }

package_sniprun() {
  pkgdesc='Compiled binary core for neovim-sniprun'
  depends=('gcc-libs')

  cd "$pkgname-$pkgver"
  install -Dm 755 target/release/sniprun -t "$pkgdir/usr/bin/"
  install -Dm 644 LICENSE -t "$pkgdir/usr/share/licenses/$pkgname/"
  install -Dm 644 README.md -t "$pkgdir/usr/share/doc/$pkgname/"
}

package_neovim-sniprun()  {
  arch=('any')
  depends=('neovim-git' 'sniprun')
  optdepends=('bash: Bash snippet support'
              'gcc: C snippets support'
              'gcc-ada: Limited Ada snippet support'
              'ghc: Haskell snippets support'
              'g++: C++ snippets support'
              'python3: Python3 snippets support'
              'jupyter: Jupyter support'
              'jupyter_console: Required with jupyter')
  install="$pkgname.install"

  cd "sniprun-$pkgver"
  find autoload doc plugin lua \
    -type f -exec install -Dm 644 '{}' "$pkgdir/usr/share/nvim/runtime/{}" \;
  install -d "$pkgdir/usr/share/nvim/runtime/target/release"
  ln -s "/usr/bin/sniprun" "$pkgdir/usr/share/nvim/runtime/target/release/sniprun"
  install -d "$pkgdir/usr/share/licenses/"
  install -d "$pkgdir/usr/share/doc/"
  ln -s "/usr/share/licenses/sniprun/" "$pkgdir/usr/share/licenses/$pkgname"
  ln -s "/usr/share/doc/sniprun" "$pkgdir/usr/share/doc/$pkgname"
}

[michaelb]

Okay, that's a lot of packages 😅. Just being curious, what's the difference between sniprun and neovim-sniprun? One's the core and the other is the plugin stuff ?

First, mind that the master and releases have always been close to each other and will continue to be so.
I mean that they are in very much sync because most of the developpent in done on dev.
Maybe that lessen the importance of a 'git' release pointing to master

Sniprun 0.5 introduced breaking changes in both sides of the communication nvim <-> core (to simplify). So no, you can't load an old core with the new plugin or vice versa.

What the installer does, is , basically: checks for the neovim version, if 0.4.x, 'git reset' to the sniprun v0.4.9 tag, effectively downgrading the 'plugin' part and fetching the 0.4.9 binary.
That way it works ok when neovim 0.4.x users clone and ./install.sh the new releases, because they will just downgrade to 0.4.9

[lmartinez-mirror]

Sorry for the late reply.

Yes, sniprun and neovim-sniprun are the core and plugin, respectively.

If master is more of a "stable" branch, then I could track dev for sniprun-git instead. I know there will be some users who will want to be on the bleeding edge.

I have gone and added the missing optdepends to the stable PKGBUILD, but omitted them from the -git releases. I'll start uploading sniprun shortly, with the rest to follow once I have them sorted out.

EDIT: Now I remember why I haven't uploaded yet. The docs aren't readable through neovim due to lack of helptags. The package can't generate them either because the neovim packages own the file, and that would cause a file conflict.

[michaelb]

tracking dev for -git seems more legit, i'm on dev myself.

What doesn't work exactly?

:help sniprun

or

:SnipInfo <interpreter_name>

If that's the latter, I may be able to do some tricks, like: if not found in the relative path, look in some hardcoded absolute path location

(And don't worry about replying late, we probably aren't in similar timezones, it's perfectly understandable)

[lmartinez-mirror]

:help sniprun doesn't work, it's an Arch Linux issue. It's nothing either of us can really fix, so I wouldn't worry about it.

[michaelb]

actually, if :SnipInfo <interpreter_name> works, it can be made to display the general help as well

[michaelb]

I've tested the AUR version of sniprun, it works great.
However, some bad decisions of mine (now "fixed", in dev and will be in v0.5.3) about error handling mean that the absence of the ressources/ directory path relative to the core will crash :SnipInfo.

It's not a problem for general usage though, sniprun will restart by itself at the next call.

The message about the bash interpreter is very thoughful.

[lmartinez-mirror]

This is a notice that I will be removing sniprun-legacy from the AUR after the main neovim package in the community repos updated to 0.5.0 a few weeks ago. I will also be listing it under the main sniprun's replaces array for those who might be using it.

[michaelb]

Sure! The 'legacy' sniprun does not make sense anymore for Arch users.

Thanks for your involvement in this !