feat: rewrite in nushell

[Elsie19]

~~We still need a way to add i18n.~~ Done.

pkgname="rhino-pkg-git"
source=("https://github.com/rhino-linux/rhino-pkg.git#branch=nushell")
arch=("all")
pkgver="2.0.0"
gives="rhino-pkg"
makedepends=("make")
pacdeps=("nutext-git")  
pkgdesc="Rhino-pkg wrapper script"
maintainer=("Oren Klopfer <[email protected]>" "Elsie19 <[email protected]>")

package() {
  cd "${gives}"
  DESTDIR="${pkgdir}" make install
  mkdir -p "${pkgdir}/usr/bin"
  install -Dm755 "${gives}" "${pkgdir}/usr/bin/${gives}"
  ln -sf "/usr/bin/${gives}" "${pkgdir}/usr/bin/rpk"
}

[Elsie19]

https://github.com/Elsie19/nu_plugin_nutext

[ajstrongdev]

Issues to note whilst testing:

• Seems to hang on snapd, when ^C is pressed this is the output:

^CError: nu::shell::column_not_found

  × Cannot find column 'Publisher'
    ╭─[/usr/share/rhino-pkg/modules/pluggables/snap.nu:19:15]
 18 │             | detect columns --guess
 19 │             | reject Publisher Version
    ·               ───┬── ────┬────
    ·                  │       ╰── cannot find column 'Publisher'
    ·                  ╰── value originates here
 20 │             | rename --column { Name: pkg }
    ╰────

• Requires support for nix and am package managers, as these can be enabled during rhino-setup

[Elsie19]

What did you search..? I need reproducible input.

[ajstrongdev]

What did you search..? I need reproducible input.

rpk search discord

[Elsie19]

Wait you said this was in a docker container?

[Elsie19]

We determined the issue only happens in a docker container.

[Elsie19]

Testing

Install nutext

Nutext is the nu plugin I made that enables us to bring gettext functionality to nu programs.

To install it, first clone the repo:

git clone https://github.com/Elsie19/nu_plugin_nutext

cd into it and run:

make build
sudo make install

Installing rpk2

rpk2 is the actual program.

To install it, first clone the repo:

git clone -b nushell https://github.com/rhino-linux/rhino-pkg

cd into it and run:

sudo make install

And you should be all good for testing!

Notes

1. Do not run in a docker container if you are testing snap functionality or if snap is installed in it at all, because it will hang

---

Reverting/uninstalling

Uninstalling

Nutext

To uninstall nutext, go back into the cloned nu_plugin_nutext project and run:

sudo make uninstall

rpk2

This is harder because it likely overwrote your bash rpk, and I haven't tested exactly, but reinstalling rpk should do the trick:

pacstall -I rhino-pkg-git
sudo rm -rf /usr/share/rhino-pkg/

[Elsie19]

Other stuff

We will have to keep nushell-bin, rhino-pkg-git, and nutext-bin tightly coupled, moreso nutext-bin and nushell-bin, as we will need to update nutext-bin for every nushell update.

[Elsie19]

Apparently you need to add the plugin in a nu shell before being able to run it. I will look more into it.

[Elsie19]

• Furthermore it seems like auto-generated help information displays beneath this

That cannot be turned off btw.

[Elsie19]

A few issues:

• Unexpected behaviors when not giving a number as an input.
• No rpk help command. It seems like you copy/pasted rpk help output to rpk -h, which presents issues. Furthermore it seems like auto-generated help information displays beneath this

There is no rpk help command. You are confusing this behavior with the catch-all flag:

https://github.com/rhino-linux/rhino-pkg/blob/0b7fc65afed6dd64b1da189adb08c27b44d977e2/rhino-pkg#L200-L203

• Using apt-remove instead of apt autoremove

That's not a command, unless you meant apt auto-remove:

https://github.com/rhino-linux/rhino-pkg/blob/0b7fc65afed6dd64b1da189adb08c27b44d977e2/rhino-pkg#L284

In which case those are the same in apt.

• Running rpk without arguments returns an error, when it should return the content of the help command.

What i mean by the first point:

• When running rpk install discord and I select no options, it will say "selecting discord from snap" and then... fail?
• When running rpk remove discord and I press enter without putting a number in, it throws an error.

Please ensure that rpk2 has consistent functionality with the first rpk.

Ok.

[oklopfer]

• Using apt-remove instead of apt autoremove

That's not a command, unless you meant apt auto-remove:

https://github.com/rhino-linux/rhino-pkg/blob/0b7fc65afed6dd64b1da189adb08c27b44d977e2/rhino-pkg#L284

Took you 2 months to figure out apt-remove isn't a command, hope it doesn't take as long to figure out that you replied to AJ's typo with a link to the old bash code that you typoed in the first place: https://github.com/rhino-linux/rhino-pkg/blob/90edb60964bc66bc85928932336d0b0c54b2d30b/modules/lib/cmd.nu#L122

Don't keep asking me to test the code if you haven't done bare minimum testing yourself. rpk cleanup is all you had to run. And given the link above, it is evident you haven't tested this basic functionality since at least before you even opened this PR.

[aadashti]

Greetings,

I am the user behind the backup and recovery ideas, which you can find here: #57 . I would be glad to continue the project and transfer those functions to this rewrite. I’d also like to contribute to the project, so I would appreciate your assistance in setting it up on my PC.

Additionally, creating an app store version of this project seems like a great idea to me. This way, we can develop and maintain Rhino Linux's app store, similar to other distributions out there—take openSUSE's YaST, for example, which I greatly admire. I can try to build a very basic beta version soon so we can start working on it. Eventually, we could offer this app store to the world under Rhino Linux's name.

Best regards,

devtracer

[ajstrongdev]

Greetings,

I am the user behind the backup and recovery ideas, which you can find here: #57 . I would be glad to continue the project and transfer those functions to this rewrite. I’d also like to contribute to the project, so I would appreciate your assistance in setting it up on my PC.

Additionally, creating an app store version of this project seems like a great idea to me. This way, we can develop and maintain Rhino Linux's app store, similar to other distributions out there—take openSUSE's YaST, for example, which I greatly admire. I can try to build a very basic beta version soon so we can start working on it. Eventually, we could offer this app store to the world under Rhino Linux's name.

Best regards,

devtracer

Hello again @devtracer

It would be great if you could port functionality into the rewrite. There is currently an ongoing discussion as to whether we continue on rewriting rhino-pkg in Nushell, or whether we pivot to an alternative such as Go or Rust. You can find and contribute to the discussion here: https://github.com/rhino-linux/tracker/issues/28

It would be best (in my opinion) to open up a separate feature proposal if you would wish to create/incorporate a graphical application store within Rhino Linux. You can do that here: https://github.com/rhino-linux/tracker

Finally, I would like to ask that you would join our Discord (if you would like to), I personally believe that you are making excellent contributions, and would love to involve you in development discussions where possible, and most of our development / discussions happen in the Rhino Linux discord server. The invite can be found here: https://discord.gg/reSvc8Ztk3

[Elsie19]

Finally, I would like to ask that you would join our Discord (if you would like to), I personally believe that you are making excellent contributions, and would love to involve you in development discussions where possible, and most of our development / discussions happen in the Rhino Linux discord server. The invite can be found here: discord.gg/reSvc8Ztk3

I would prefer technical discussions about rhino-pkg to be here rather than on discord.

[aadashti]

Hello again @devtracer

It would be great if you could port functionality into the rewrite. There is currently an ongoing discussion as to whether we continue on rewriting rhino-pkg in Nushell, or whether we pivot to an alternative such as Go or Rust. You can find and contribute to the discussion here: rhino-linux/tracker#28

It would be best (in my opinion) to open up a separate feature proposal if you would wish to create/incorporate a graphical application store within Rhino Linux. You can do that here: https://github.com/rhino-linux/tracker

Finally, I would like to ask that you would join our Discord (if you would like to), I personally believe that you are making excellent contributions, and would love to involve you in development discussions where possible, and most of our development / discussions happen in the Rhino Linux discord server. The invite can be found here: https://discord.gg/reSvc8Ztk3

Hi @ajstrongdev,

Thank you for the update and the invite! I’d be happy to participate in the discussions and contribute further to the team. I’ll make sure to check out rhino-linux/tracker#28 soon.

Regarding the graphical application store, I’ll open a separate feature proposal on the tracker to discuss it in more detail. I plan to develop the GUI app store's backend in a way that allows it to seamlessly attach and connect to the package manager. This approach will ensure a stable and seamless connection, even as the package manager undergoes frequent updates.

I’m really thrilled to hear that you’re happy with my contributions so far—I truly appreciate the feedback! Thanks again for the invite; I’ll join the Discord server soon to start discussions!

Best wishes, @amirali-dashti

[ajstrongdev]

I've tested with pacstall and apt installed in my docker image (as flatpaks and snaps will not work). This seems to have massively improved. I still need to test snap/flatpak functionality but two things to note:

• We should really include Nixpkgs and AM support.
• If possible I would like to change the rpk remove output so that it does not display within a table.

[aadashti]

Hello,

As you're building the next generation of the package, should the GUI application also be included in this build? I was thinking of an installation window where users would be able to press the installation button alongside choosing a package manager to install with. The GUI app's backend will lead to some functions that call these codes.

Feel free to share what you think. I think users would like to try this app's beta version as well.

[ajstrongdev]

Hello,

As you're building the next generation of the package, should the GUI application also be included in this build? I was thinking of an installation window where users would be able to press the installation button alongside choosing a package manager to install with. The GUI app's backend will lead to some functions that call these codes.

Feel free to share what you think. I think users would like to try this app's beta version as well.

@amirali-dashti Hello. Please do understand that the GUI application store is currently a proposal, this rewrite is not intending to nor will support functionality for that. Furthermore I feel as though, with the GUI app store issue still "a proposal" and not an agreed upon feature, that you might be getting a bit ahead of yourself :smile:

What would be great is if someone could contribute support for the Nix and AM package managers into this rewrite, as that is where our focus should be at the moment, feel free to submit a Pull Request into the nushell branch.

[aadashti]

@amirali-dashti Hello. Please do understand that the GUI application store is currently a proposal, this rewrite is not intending to nor will support functionality for that. Furthermore I feel as though, with the GUI app store issue still "a proposal" and not an agreed upon feature, that you might be getting a bit ahead of yourself :smile:

What would be great is if someone could contribute support for the Nix and AM package managers into this rewrite, as that is where our focus should be at the moment, feel free to submit a Pull Request into the nushell branch.

@ajstrongdev Thanks for the reply. I understand, I thought a basic, early agreement would be enough to start building a template version of the proposal alongside this new project, to check if whether this project passes and gets approved or not; similar to a laboratory's research process.

I've tried Nix, and I have to say I've liked it so far. nix-env -qaP <package-name> searches for all of the available packages. Furthermore, this scripts installs a particular package: nix-env -i <package_name>. The other approach would be an auto editor script to edit the environment.systemPackages of configuration.nix. I think you can add the nix support with copying one of those other package manager's scripts and changing the commands with these, which I've mentioned here. I can do it if you want, but this's the idea I have in mind for adding Nix package manager.

[aadashti]

@ajstrongdev To confirm, as you've mentioned here, the GUI app will be continued once it passes the proposal stage 👍🙏

[oklopfer]

just did some testing with:

pkgname="rhino-pkg-git"
source=("https://github.com/rhino-linux/rhino-pkg.git#branch=nushell")
arch=("all")
pkgver="2.0.0"
gives="rhino-pkg"
makedepends=("make")
pacdeps=("nutext-git")  
pkgdesc="Rhino-pkg wrapper script"
maintainer=("Oren Klopfer <[email protected]>")

package() {
  cd "${gives}"
  DESTDIR="${pkgdir}" make install
  mkdir -p "${pkgdir}/usr/bin"
  install -Dm755 "${gives}" "${pkgdir}/usr/bin/${gives}"
  ln -sf "/usr/bin/${gives}" "${pkgdir}/usr/bin/rpk"
}

overall is very good, there was a search hanging issue I experienced a while back that I still need to test, but almost everything is quite solid now. Few minor things:

1. this "are you sure" prompt is missing in the rewrite:

2. as is this one:

3. this should say packages plural:

4. Ideally we want to figure out how to filter out pacstall packages from apt queries:

But again, overall great job and solid improvements. I also think it would be great if we could get the lists to spread out into multiple columns.

[ajstrongdev]

@ajstrongdev Thanks for the reply. I understand, I thought a basic, early agreement would be enough to start building a template version of the proposal alongside this new project, to check if whether this project passes and gets approved or not; similar to a laboratory's research process.

I've tried Nix, and I have to say I've liked it so far. nix-env -qaP <package-name> searches for all of the available packages. Furthermore, this scripts installs a particular package: nix-env -i <package_name>. The other approach would be an auto editor script to edit the environment.systemPackages of configuration.nix. I think you can add the nix support with copying one of those other package manager's scripts and changing the commands with these, which I've mentioned here. I can do it if you want, but this's the idea I have in mind for adding Nix package manager.

@ajstrongdev To confirm, as you've mentioned here, the GUI app will be continued once it passes the proposal stage 👍🙏

@amirali-dashti Again, you are free to write the code for it, you are allowed to do that obviously, I just do not want to make any promises of this being merged when it is still a very early discussion, and for you to see the progress you've made as "wasted time" if we do not agree on the proposal or implementation. Many members of the team are yet to give a solid response, please do allow time for this, as we are volunteer maintainers and have our own personal lives.

I thought a basic, early agreement would be enough to start building a template version of the proposal alongside this new project.

This is not usually how we do things. We typically agree on a proposal and initial concept before beginning development. Again, there is nothing stopping you from writing the program, but I will not make any guarantees that the implementation you design will be merged.

[aadashti]

@amirali-dashti Again, you are free to write the code for it, you are allowed to do that obviously, I just do not want to make any promises of this being merged when it is still a very early discussion, and for you to see the progress you've made as "wasted time" if we do not agree on the proposal or implementation. Many members of the team are yet to give a solid response, please do allow time for this, as we are volunteer maintainers and have our own personal lives.

This is not usually how we do things. We typically agree on a proposal and initial concept before beginning development. Again, there is nothing stopping you from writing the program, but I will not make any guarantees that the implementation you design will be merged.

Hello @ajstrongdev,

I appreciate you explaining and outlining the process. To ensure alignment, I'd be happy to contribute to the proposal discussion. Therefore, as discussed, we'll continue the discussion here: https://github.com/rhino-linux/tracker/issues/39#issue-2864035031 . I look forward to contributing to the proposal process.

best regards.

[Elsie19]

4. Ideally we want to figure out how to filter out pacstall packages from apt queries

We actually do, the issue is that we don't change the Section key in -deb packages, so we don't (based solely on the aptitude query) know about those packages, but we do accurately filter out any non-deb package.

[Elsie19]

@oklopfer @ajstrongdev rereview please.

[oklopfer]

1. This prompt was fixed but there is no space after the y/N:

2. Same here:

3. If I select nothing it still shows the prompt:

4. All removals of APT packages hang (@ajstrongdev and I both tested and confirmed):

5. Install uses nala (if available), remove doesn't work so idk what it uses, and cleanup seems to only use APT:

[Elsie19]

3. If I select nothing it still shows the prompt:

I believe that is rpk1 behavior:

https://github.com/rhino-linux/rhino-pkg/blob/66de28f1a3bfe9a4ae8062110877a6f4bcd6e667/rhino-pkg#L387-L388

[oklopfer]

4. Ideally we want to figure out how to filter out pacstall packages from apt queries

We actually do, the issue is that we don't change the Section key in -deb packages, so we don't (based solely on the aptitude query) know about those packages, but we do accurately filter out any non-deb package.

We require deb packages to put the actual package name in gives always, so can't we just parse out any _gives results from /var/lib/pacstall/metadata/*-deb in addition?

[oklopfer]

4. Ideally we want to figure out how to filter out pacstall packages from apt queries

We actually do, the issue is that we don't change the Section key in -deb packages, so we don't (based solely on the aptitude query) know about those packages, but we do accurately filter out any non-deb package.

We require deb packages to put the actual package name in gives always, so can't we just parse out any _gives results from /var/lib/pacstall/metadata/*-deb in addition?

Also importantly actually, pacstall packages should be parsing their pacstall versions from metadata, not their apt versions:

This may actually be something we have to fix in Pacstall, as -Ci parses from dpkg instead of metadata, leading to mismatches:

This is a bit of a convoluted issue though, because we use this query on other places:

1. For -Ci, I think we can keep -Ci version as is, but perhaps we can add a -Ci pkgver option which reads from the already provided ${_version} variable in metadata instead of from dpkg, giving the pacstall version instead of the apt version.

2. For the reinstall warning, we should just simply be parsing -Ci pkgver instead of dpkg, since the pacstall version is the one that matters if pacstall is performing a reinstall.

3. For the version constraints, it should probably be left untouched (keep it using the apt/dpkg version), since thats the actual version that dpkg/aptitude will be checking on constraints.