lure-sh / lure Goto Github PK

AUR helpers do this with AUR packages, so it would make sense for lure to do this. This could also go a long way in allowing packages to be built on multiple Linux distros.

LURE sets a few environment variables in genBuildEnv(). These should be documented.

Just curious: is this not possible currently? obsidian.desktop creation in lure-repo for example is imho horrendous currently and could just be stored as e.g. obsidian/files/obsidian.desktop alongside obsidian/lure.sh and installed to ${pkgdir} from the directory.

For reference on Void's xbps-src this is possible with the ${FILESDIR} global variable.

Hi!

Thanks for creating such a wonderful piece of software! I've discovered a slight issue while updating my fedora system... Fedora tries to install a different package named "lure".

A quick and easy solution would be to change the package name to something like lure-package-manager or something else.

~ 
❯ dnf info lure        
Last metadata expiration check: 2:59:46 ago on Mon 24 Oct 2022 11:08:11 AM CEST.
Installed Packages
Name         : lure
Version      : 0.0.2
Release      : 1
Architecture : x86_64
Size         : 15 M
Source       : lure-0.0.2-1.src.rpm
Repository   : @System
Summary      : Linux User REpository
URL          : https://gitea.arsenm.dev/Arsen6331/lure
License      : GPLv3
Description  : Linux User REpository

Available Packages
Name         : lure
Version      : 1.1
Release      : 24.fc36
Architecture : noarch
Size         : 5.0 M
Source       : lure-1.1-24.fc36.src.rpm
Repository   : fedora
Summary      : Lure of the Temptress - Adventure Game
URL          : http://www.revolution.co.uk/_display.php?id=10
License      : Freely redistributable without restriction
Description  : Lure of the Temptress was Revolution's very first adventure game
             : and work began on it in 1989, even before Revolution's inception
             : as an actual games development company. From the start our aim
             : was to consider the contemporary adventures of the day and then
             : bring something new to the genre. From this came the Virtual
             : Theatre engine. VT allowed in-game characters to wander around
             : the gameworld indepently of each other, living their own lives
             : and doing their own thing. Another feature allowed the player to
             : give direct orders to Helper characters - in this case Ratpouch -
             : who would then go off to perform the task.
             : 
             : The result is a quirky and entertaining adventure game that
             : kicked off Revolution's fondness for characterisation and in-game
             : humour.

lure does not remove the dependency along with the main package if it was also installed using lure

I discovered this with the syncthing package and its dependency, which I added to the repository

The title is a bit strange, but I'll explain the idea:

We are all aware of the fact that dependencies are named different things on different distros. (Such as LibX11-dev on debian distros being called LibX11-devel on RPM distros). These being called different things is what the lure is trying to solve already.

However, if you want to make this a lot easier for developers, my idea is to have a website to search for these packages and automatically give the known name across each distro. This would be much better as right now I would have to guess what a dependency name on one distro would be on a different one, or just frantically google until you eventually get your answer. A website would make this easier for developers to automatically add support for each distro they figure out the package name, and may just get more developers interested in publishing to the lure.

Maybe this checking dependencies for each distro has been done for some other project, and if so I would be interested in viewing that website (as ironically enough it would help me figure out some dependencies I need to compile a program right now)

Thanks!

Here's a idea that might make maintaining a lure pkg a bit easier.

So we keep the lure.sh script but we add more scripts like "fedora.sh" which contains overrides for deps, build, package, etc but without all of the main variables like version and name. So keep "build_deps" and "deps" and move the "fedora-deps" into its own file.

This would eliminate the need for 10+ lines of different distro specific changes.

Hi,

just tried lure and it looks really promising.
I did a lure build which created a deb package because I am on a Ubuntu system.

It would be nice to create other package formats from the current Distro.
Something like:

LURE_PKG_FORMAT=apk lure build
LURE_PKG_FORMAT=rpm lure build
...

(similar to GOOS=windows go build)

From what I could gather right now the lure CLI tool will always print messages in English, it would be great if translations/localization support was implemented to increase the reach of this tool.

For package lure.sh files at least desc should get localized/translated also one way or another as found in the discussion on lure-sh/lure-repo#30; one way to go about this would be to store the translation along with the package directly with e.g.

desc='User-friendly tool for working with Active Directory domains and group policies'
desc_ru='user-friendly инструмент для Linux для работы с доменом Active Directory и групповыми политиками.'

Perhaps the translations should be in a separate file to avoid unnecessary merge conflicts etc. but that's more of an implementation detail if this is the way decided to go forward with.

Another way to potentially deal with desc translation would be to depend on a CLI translator tool such as https://www.soimort.org/translate-shell/, but that might not be ideal for a number of reasons, perhaps even a combination of the 2 can be implemented, i.e. if localization of the UI language is configured via LC_* or so and desc_<lang> exists use that (added in case automatic translation is bad for example), otherwise fallback to trans -brief "${desc}".

I created a lure repo for myself just for testing:

https://github.com/vaporup/lure-repo

Building something brings this deprecation warning

DEPRECATION WARNING: Leaving the 'maintainer' field unset will not be allowed in a future version

I looked in the sourcecode of lure and nfpm
but could not figure out how to set this Maintainer field...

Checking the built packages, the Maintainer field is either set to some default or completely missing:

deb

dpkg-deb -I ssh-tools_1.7-1_amd64.deb | grep Maint

Maintainer: Unset Maintainer <unset@localhost>

rpm

rpm -qip ssh-tools-1.7-1.x86_64.rpm | grep Packager

Packager    : 

archlinux

in .PKGINFO of ssh-tools-1.7-1-x86_64.pkg.tar.zst

packager = Unknown Packager

apk

Nothing in .PKGINFO of ssh-tools_1.7-1_x86_64.apk

Although according to the documentation this should not be happening.

I am using

scripts=(
    ['postupgrade']='postupgrade'
    ['postinstall']='postinst'
    ['preremove']='prerm'
    ['postremove']='postrm'
)

in the script, but the resulting deb package does only contain prerm and postrm.

It works fine for the archlinux package though.

i'm using linux mint 20.2 uma and have built lure using latest commit 46e0343

1. ./lure upgrade does nothing when there are packages to be upgraded

~/projects/lure ❯ apt list --upgradable -a
Listing... Done
timeshift/uma 22.06.5+una amd64 [upgradable from: 20.11.1.1+ulyssa]
timeshift/now 20.11.1.1+ulyssa amd64 [installed,upgradable to: 22.06.5+una]
timeshift/focal 20.03+ds-2 amd64

~/projects/lure ❯ ./lure upgrade
5:33AM INF There is nothing to do.
~/projects/lure ❯

2. ./lure info <pkg> command fails no matter what

~/projects/lure ❯ ./lure info firefox
5:38AM FTL Error finding package error="package 'firefox' could not be found in any repository"
~/projects/lure ❯

3. ./lure refresh always gives same output

~/projects/lure ❯ ./lure refresh
5:40AM INF Pulling repository name="default"
5:40AM INF Repository up to date name="default"
~/projects/lure ❯

4. ./lure list shows only single result

~/projects/lure ❯ ./lure list
itd-bin 0.0.7
~/projects/lure ❯

shouldn't listCmd function be something like this?

func listCmd(c *cli.Context) error {
	mgr := manager.Detect()
	if mgr == nil {
		log.Fatal("Unable to detect supported package manager on system").Send()
	}

	pkgs, _ := mgr.ListInstalled()
	for name, version := range pkgs {
		fmt.Println(name, version)
	}

	return nil
}

this prints all the installed packages

I see that the LURE script format is intended to be very similar to that of the AUR PKGBUILD, but why the change in variable names

LURE uses variables like: name, version, release, desc, homepage, architectures, deps
The AUR equivalents being: pkgname, pkgver, pkgrel, pkgdesc, url, arch, depends

I know you've mentioned wanting to at some point make a tool to convert AUR PKGBUILDs into LURE scripts so wouldn't it be simpler to reduce the inconsistencies where they offer no value.

This is a very interesting project but it would be nice to be able to update it after installation in a seamless manor. Here's a few ideas of how this could be done:

• Self updater just like yay on Arch (Updates itself through the AUR)
• Package in distro repos which will be pretty annoying / difficult to maintain
• Some way to curl the latest release (.rpm, .deb, apk, etc...) just like GitHub allows you to do

Thanks in advance! :)

Others may help, it must be, and would be great. I want to add it on my website and YouTube thumbnails.

I can't figure out how to use preinstall scripts. For example, I need to include a 32-bit architecture or a non-free repository in debian. How can I do this in lure.sh ?

I have some packages (e.g. syncthing) that are available in the default repo, but but I want them not to be touched by lure as my distro repositories already handle it and I'd rather stay with that version. It'd be great if there were an option to ignore certain packages. It'd be useful for git packages too, where I might not wanna update them every time. Also, if I want to stick to a version for any particular reason (e.g. bugs).

A separate e.g. installmisc target for non-binary files (which install depends on) would be nice so it can be called separately from e.g. the Void package build template where (cross-)building Go packages is handled with a build-style and a corresponding environment, and for non-binaries just this would be then needed:

post_install() {
    make PREFIX=/usr DESTDIR=${DESTDIR} installmisc
}

I previously sent https://lists.sr.ht/~craftyguy/superd/patches/36158 which the Void package handles in a similar way.

Copied mostly from #46 as I didn't get any particular feedback to this suggestion yet.

again, just like PKGBUILD a function to pull package version from the git repo would be nice, cause git packages don't really need modifications

https://nixos.wiki/wiki/Nix_package_manager

If the package is built from the source code, then when updating, you will find out that the update is not required only after the compilation is finished. Maybe it's worth doing a check before compiling?

Related: #17 (comment)

These should be integrated to the Makefile and install.sh script.

As for the Makefile I'd like to ask for a separate e.g. installmisc target for non-binary files (which install depends on) so they can be called separately from e.g. the Void package build template where (cross-)building Go packages is handled with a build-style and a corresponding environment, and for non-binaries just this would be then needed:

post_install() {
    make PREFIX=/usr DESTDIR=${DESTDIR} installmisc
}

I previously sent https://lists.sr.ht/~craftyguy/superd/patches/36158 which the Void package handles in a similar way

Perhaps a bit off-topic for this issue but there also should be an installation path $(DESTDIR)$(PREFIX)/... paradigm for the files with PREFIX defaulting to /usr/local in the Makefile so distributions can override these for packaging purposes.

I wrote lure.sh for noisetorch, but an error occurs at the sources download stage.

https://gitflic.ru/project/xpamych/xpamych-lure-repo/blob?file=noisetorch%2Flure.sh

I can't get git sources by typing git+repoaddress. Tested on Fedora, Debian and Arch Linux in same day.

I always get this output:

goroutine 1 [running]:
main.getSources({0xd9aa90, 0xc0001d8e00}, {0xc00003a0f0, 0x2d}, 0xc0002ba000)
        /home/appveyor/projects/lure/build.go:445 +0x29e
main.buildPackage({0xd9aa90, 0xc0001d8e00}, {0xc6d837, 0x7}, {0xd9ec20, 0x1338a90})
        /home/appveyor/projects/lure/build.go:216 +0x978
main.buildCmd(0xc0001d9100)
        /home/appveyor/projects/lure/build.go:94 +0xe5
github.com/urfave/cli/v2.(*Command).Run(0xc000290120, 0xc0001d8f80)
        /home/appveyor/.gvm/pkgsets/go1.19/global/pkg/mod/github.com/urfave/cli/v2@v
2.16.3/command.go:173 +0x6ca
github.com/urfave/cli/v2.(*App).RunContext(0xc0001628c0, {0xd9aa90?, 0xc0001d8e00},
{0xc000136000, 0x2, 0x2})
        /home/appveyor/.gvm/pkgsets/go1.19/global/pkg/mod/github.com/urfave/cli/v2@v
2.16.3/app.go:383 +0xfde
main.main()
        /home/appveyor/projects/lure/main.go:134 +0xd25

First thank you for creating this awesome tool.

I am trying to use lure in a CI / CD pipeline and as such it would be very useful to be able to have the option to let lure move the built packages into the current folder instead of placing it inside ~/.cache/lure/pkgs.

Furthermore when cross-packaging, lure does delete the previously built package inside ~/.cache/lure/pkgs (for example when doing lure build && LURE_PKG_FORMAT=archlinux lure build there will only be the .pkg in that folder).

Hi there, im a openeuler developer, this project is a good idea, and we want to port it into openeuler community, do you think it's a good time to do this? I'm glad to do some sorts of the port working :)

I'm trying to install this script. This works properly when tested locally. However, the installation fails when when installing from repo.

I added the echo in package() function, which shows that the $version isn't properly updated.

I think a better idea would be to run this version() function before getting the source, then this script won't have to do everything in package().

Also, even though I added all inside architectures, I get the warning

"Your system's CPU architecture doesn't match this package. Do you want to build anyway?"

Replacing all by amd64 seems to mitigate this, but I don't think that this should happen.

I would like to suggest some improvements to lure ls.

1. As per discussion in #40, add an optional argument for lure ls, presumably lure ls installed, to only list installed packages. Almost all other package managers provide this (e.g. pacman -Q, paru -Q, apt list --installed, dnf list --installed etc.), so I think this is a very important feature to have.
2. Group packages by repository when listing them. This should be similar to what dnf list --installed outputs.
3. Instead of cross-referencing with the package manager each time when getting this list described in 2 (also applies to lure up), maybe it'd be a better idea to have a list somewhere. A simple txt or json file should suffice.

when I try to run to check the health of the script I am writing , lure tries to install espanso-bin, although it is not in the list of required dependencies.

I have created a repository and a framework for installing obsidian
https://gitflic.ru/project/xpamych/xpamych-lure-repo/blob?file=obsidian%2Flure.sh
however, when trying to install
lure in obsidian
I get an error. Tell me where to dig?

panic: runtime error: index out of range [0] with length 0

goroutine 1 [running]:
main.getSources({0xd9aa90, 0xc00024ee40}, {0xc000164b00, 0x37}, 0xc0000ce000)
	/home/appveyor/projects/lure/build.go:445 +0x29e
main.buildPackage({0xd9aa90, 0xc00024ee40}, {0xc0004e3400, 0x48}, {0xd9ebb0, 0x1338ab0})
	/home/appveyor/projects/lure/build.go:216 +0x978
main.installScripts({0xd9aa90, 0xc00024ee40}, {0xd9ebb0?, 0x1338ab0}, {0xc0004f4440?, 0x1, 0x9a9bb6?})
	/home/appveyor/projects/lure/install.go:64 +0xc5
main.installPkgs({0xd9aa90, 0xc00024ee40}, {0xc0002e8e20, 0x1, 0x1}, {0xd9ebb0?, 0x1338ab0?})
	/home/appveyor/projects/lure/install.go:59 +0x179
main.installCmd(0xc00024f0c0)
	/home/appveyor/projects/lure/install.go:39 +0x155
github.com/urfave/cli/v2.(*Command).Run(0xc00014f9e0, 0xc00024efc0)
	/home/appveyor/.gvm/pkgsets/go1.19/global/pkg/mod/github.com/urfave/cli/[email protected]/command.go:173 +0x6ca
github.com/urfave/cli/v2.(*App).RunContext(0xc0001568c0, {0xd9aa90?, 0xc00024ee40}, {0xc00011c000, 0x3, 0x3})
	/home/appveyor/.gvm/pkgsets/go1.19/global/pkg/mod/github.com/urfave/cli/[email protected]/app.go:383 +0xfde
main.main()
	/home/appveyor/projects/lure/main.go:134 +0xd25

lure.sh looks like a standalone shell script. I guess PKGBUILD would not be a good choice since it is not compatible with pacman and makedeb.

How about one of these?

• PKGBUILD.lure
• PKGBUILDLURE
• PKGBUILD_LURE
• LUREPKGBUILD
• LURE_PKGBUILD
• LURE_BUILD
• LUREPKG
• LURE_PKG

lure.sh could still be used for backward compatibility

Is it possible to add auto-completion to future plans to search for packages from operating system repositories and external repositories by pressing the tab button?

I think it makes sense to make the repository pre-selected by default, if there are several repositories. Or remember the last selected repository.

Currently, the LURE repo is a simple Github repo that contains directories that represent packages. I would like to create a web interface similar to aurweb that hosts packages and shows information about them.

This is neat as then you don't have to manually always type these deps out for each package that are mandatory based on linked libraries, just ones that appear to be required on runtime if they're e.g. called from a shell script.

A database like this also avoids duplicating known names for certain packages on different distros across a bunch of lure.sh's.

This could work similar to what Void's xbps-src does with 04-generate-runtime-deps.sh and 06-shlib-provides pre-pkg hooks; for this we would at least need to map out each library .so*'s (seen in e.g. objdump / ldd output of binaries) to package names for each distro in some way (while ideally avoiding duplicating .so* -> package names for each distro/arch if possible), for example here's how Void does it.

On Arch PKGBUILDs you can also do e.g. depends+=(libmount.so libffi.so) or provides+=(libgio-2.0.so libglib-2.0.so libgmodule-2.0.so libgobject-2.0.so libgthread-2.0.so) which mapping out the provided package names -> .so*s could also enable.

When installing a package that requires compilation in ArchLinux via yay and the time for entering the password expires, when the installation command is run again, it continues, in lure we start from the beginning. It may be worth considering the possibility of continuing the installation so as not to compile again.

It is not possible to use the flags of the package manager, in cases where it is necessary to overwrite or ignore the package. For example, go-bin: in my distribution, the version is lower than in lure and it tries to install it when updating, but there is a conflict that cannot be resolved.

I made a typo in the name of one of the packages in my repo. After fixing that name, lure ref does fetch the new package, but it also keeps the old one (i.e. it shows up in lure list). Had to manually delete ~/.cache/lure/ and lure ref to get rid of it.

Aur helpers like yay and pikaur ask the user if they want to remove the build dependencies after install just like lure, but they only remove the build deps that were installed when the command was executed. Lure doesn't do this which could and has in my case, remove needed packages that were explicitly installed by the user

I'm not asking you to add this support, mainly made this as a reminder for myself to look into it one day :)

Looking under manager/ it doesn't look that bad to implement.

Distro: https://voidlinux.org/
Package manager: https://github.com/void-linux/xbps
Docs: https://docs.voidlinux.org/xbps/index.html

I'm attempting to write an install script for k9s. But it looks like the tarball specified with the sources_amd64 variable is not restoring permissions on auto extraction.

The lure.sh script looks like this:

name=k9s
version=0.26.6
release=1
desc='TUI for managing Kubernetes clusters and pods'
homepage='https://github.com/derailed/k9s'
architectures=('amd64')
license=('APACHE')
provides=('k9s')

sources_amd64=("https://github.com/derailed/k9s/releases/download/v0.26.6/k9s_Linux_x86_64.tar.gz")
checksums_amd64=('7abe5d029a29d8108ab405889ea2a8f731765d79333920ac7c2942c6e16d1bd4')

package() {
  ./k9s completion bash | install -Dm644 /dev/stdin "$pkgdir/usr/share/bash-completion/completion/k9s"
  ./k9s completion zsh | install -Dm644 /dev/stdin "$pkgdir/usr/share/zsh/site-functions/_k9"
  ./k9s completion fish | install -Dm644 /dev/stdin "$pkgdir/usr/share/fish/vendor_completions.d/k9s.fish"
  install -Dm755 "./$name" "$pkgdir/usr/bin/$name"
  install -Dm644 ./LICENSE "$pkgdir/usr/share/licenses/$name/LICENSE"
}

This is the contents of ~/.cache/lure/pkgs/k9s/src after running lure build:

l ~/.cache/lure/pkgs/k9s/src
total 55M
drwxr-xr-x. 1 ---------- ---------- 38 Oct 18 21:49 .
drwxr-xr-x. 1 ---------- ---------- 12 Oct 18 21:49 ..
-rw-r--r--. 1 ---------- ---------- 55M Oct 18 21:49 k9s
-rw-r--r--. 1 ---------- ---------- 10K Oct 18 21:49 LICENSE
-rw-r--r--. 1 ---------- ---------- 34K Oct 18 21:49 README.md

k9s should have execute permissions, and it does if I manually extract the tarball using tar -xvf k9s_Linux_x86_64.tar.gz.

I can make it work by adding a chmod to the package function, however the Arch AUR PKGBUILD (which this is based on) works as expected.

Was this intended behaviour?

I created a lure repo for myself just for testing:

https://github.com/vaporup/lure-repo

The package ssh-tools is just a bunch of scripts.

I looked in the sourcecode of lure and nfpm but I am not sure
how to use the architectures var for scripts.

In Debian-based distros all is used
and distros which use rpm, apk, pacman often it is noarch

This is also reflected in the package filenames.

If I use architectures=('all') or completely remove the variable,
the package filename and metadata in the package shows the current architecture of the build host.

deb

dpkg-deb -I ssh-tools_1.7-1_amd64.deb | grep Arch

Architecture: amd64

archlinux

In .PKGINFO of ssh-tools-1.7-1-x86_64.pkg.tar.zst

arch = x86_64

does not pick up dependencies for Fedora

Support for lure on nixos and nix shell files like default.nix to be able to develop lure on nix more efficiently

maybe just do it as PKGBUILD does it like this
'sirit::git+https://github.com/ReinUsesLisp/sirit'

I'm familiar with Void's xbps-src and the package build templates and thought the following would be neat over here as well and shouldn't be out of scope either :)

Here's a few things that could be done instead of the original lines I see in lure.sh files to shrink some of the common actions you'd want to do in a package():

• Binaries (${pkgdir}/usr/bin)

  • install -Dm755 "${srcdir}/${name}/build/admc" "${pkgdir}/usr/bin/admc"
install_bin "${srcdir}/${name}/build/admc"
    • second arg for changing install target filename, e.g. install_bin Espanso-X11.AppImage espanso
    • without any args install_bin could set source file to just ${name}? not sure if this makes sense, maybe if enough packages essentially would repeat install_bin ${name} basically
    • see Void's vbin

• Systemd user services (${pkgdir}/usr/lib/systemd/user)

  • install -Dm644 "systemd.service" "${pkgdir}/usr/lib/systemd/user/espanso.service"
install_systemd_user systemd.service espanso.service
    • second arg for changing install target filename
    • see Void's vsv

• Systemd services (${pkgdir}/usr/lib/systemd/system)

  • install -Dm644 "${srcdir}/syncthing-relaysrv.service" "${pkgdir}/usr/lib/systemd/system/syncthing-relaysrv.service"
install_systemd "${srcdir}/syncthing-relaysrv.service"
    • second arg for changing install target filename
    • see Void's vsv

• Config files (${pkgdir}/etc)

  • install -Dm644 "./itd.toml" ${pkgdir}/etc/itd.toml
install_conf itd.toml
    • second arg for changing install target filename?
    • see Void's vconf

• License files (${pkgdir}/usr/share/licenses/${name})

  • install -Dm644 "./LICENSE" "${pkgdir}/usr/share/licenses/itd/LICENSE"
install_license LICENSE
  • without any args install_license could set source file to just LICENSE?
  • see Void's vlicense

• Shell completions (for bash, zsh and fish)

  • ./k9s completion bash | install -Dm644 /dev/stdin "$pkgdir/usr/share/bash-completion/completion/k9s"
install_completion "./k9s completion bash" bash k9s
  • ./k9s completion zsh | install -Dm644 /dev/stdin "$pkgdir/usr/share/zsh/site-functions/_k9s"
install_completion "./k9s completion zsh" zsh k9s
  • ./k9s completion fish | install -Dm644 /dev/stdin "$pkgdir/usr/share/fish/vendor_completions.d/k9s.fish"
install_completion "./k9s completion fish" fish k9s
  • first arg would either be file to install (has to exist) or a command to generate the completions which will be installed from /dev/stdin
  • without third arg install_completion could set command to install completions for to just ${name}?
  • see Void's vcompletion

• Manual pages (${pkgdir}/usr/share/man)

  • install -Dm644 man/strelaysrv.1 "${pkgdir}/usr/share/man/man1/${name}.1"
install_man man/strelaysrv.1
  • see Void's vman

• Desktop files (${pkgdir}/usr/share/applications)

  • install -Dm644 "${srcdir}/${name}/share/admc.desktop" "${pkgdir}/usr/share/applications/admc.desktop"
install_desktop "${srcdir}/${name}/share/admc.desktop"
    • second arg for changing install target filename?

• Libraries (${pkgdir}/usr/lib)

  • install -Dm644 "${srcdir}/${name}/build/libadldap.so" "${pkgdir}/usr/lib/libadldap.so"
install_lib "${srcdir}/${name}/build/libadldap.so"

  A lot of these could just be one-liner bash functions that are included before running package function, for example:

  install_bin() { install -Dm0755 "$1" -t "${pkgdir}/usr/bin/${2:-${1//*\/}}"; }

  Thoughts?

I've been using Nix for the past few months now, and I love it. One thing I've definitely missed, though, is the AUR since I moved from arch. Nix's sandboxing techniques make me feel that it'd be harder to integrate LURE with, but there's lots of other PMs that work with nix (npm, cargo, go, etc). I'd love to know if you have any thoughts or plans on this.