oni2
oni2 copied to clipboard
onivim
Build oni2 as a nix package in Nixpkgs
Hello,
For people running the NixOS Linux distribution (or simply the Nix package manager), AppImage is not the ideal format.
I was wondering if it was possible to build oni2 from sources as a nix package?
I don't have strong skills in building nix packages, but I might give it a shot. I am just creating this issue so there is an open topic in case it reaches another nix user interested in onivim.
I haven't seen any tool in the Nixpkgs collection built with esy yet, but I need to double-check whether it is possible or not.
Maybe more as a general question toward maintainers: what is your opinion about distributing oni2 through additional Linux package managers? Is it something that could be considered in the future?
As a side note, nix is a package manager that can be installed on many Linux distribution. That would allow having another way of installing it for Linux users.
Thanks, Loric
A new attempt to integrate esy into Nixpkgs is happening: https://github.com/NixOS/nixpkgs/pull/96234
In the meantime, I build oni2 from the AppImage using the appimageTools.wrapType2 nix helper. For those interested in knowing how, here is below the link to my home-manager configuration.
https://github.com/lobre/nix-home/blob/66b6572db3459494583de8843ecd5fb12723ba01/home/gui/oni2.nix
To be aware that the AppImage should be downloaded and placed into the "./oni2" directory before the nix build.
I don't believe that the PR to package esy in Nixpkgs will help much. All it does is package esy itself to run on nixos, it does not facilitate using esy to build inside of a nix derivation. See this issue for discussion from the opam2nix creator on building nix packages with esy.
Thanks, @xavierzwirtz for clarifying that. I thought naively that it would help and did not get that it was a different battle. I am not super comfortable with oni’s build environment (revery, ocaml, esy and all the jazz).
The other issue you referenced seems to be stuck for a while so I am not sure it would help for a short term solution here.
Nix is known to be a package manager that builds from sources, but I start to feel that using the AppImage might still be the best option for oni as it seems to be the format of choice for Linux platforms. The only drawback at the moment is that this AppImage is not distributed publicly. One needs a license key to be able to download the file. Nix cannot download it if it is not available at a public location (maybe related to https://github.com/onivim/oni2/issues/1154).
I think we could just wait for the MVP of oni, expecting that we will effectively have a better distribution of the software and hoping that we could use it in a Nix package. Maybe people from the team would have initial thoughts about this (@bryphe)?
Thanks!
Has a "work around" for anyone on nixos there is "appeimage-run" that let you use the editor without hassle
As said above, as long as onivim,'s AppImage is not distributed publicly (using Github releases for instance), it is kind of difficult to automate the build with nix. You need to manually download first the AppImage, and then launch your nix build.
Not super convenient effectively...
Here might be another handy link: https://github.com/esy/esy/pull/994
I'm using Nix on ubuntu and currently I don't use Nix to manage oni2, it would be nice if it could be, but I feel like this is something later down the road.
I'm working on it. But it's waaaay too hacky.
https://gist.github.com/gardspirito/3215d95a7af8268cf7757a7ddf47b970 [broken] In my case, though, it suffers because of #3772
Maybe more as a general question toward maintainers: what is your opinion about distributing oni2 through additional Linux package managers? Is it something that could be considered in the future?
The whole reason of limiting the number of package formats to just one universal format is probably to avoid spending the considerable amount of time needed for keeping |n| number of distribution specific packages up-to-date. And once you open up for one, the requests for all the rest will surely follow. Better to request this from the distribution's package maintainers, not the core developer(s) of a specific app.
And once you open up for one, the requests for all the rest will surely follow. Better to request this from the distribution's package maintainers, not the core developer(s) of a specific app.
To me, deploying an application is part of the development lifecycle, and therefore is the responsibility of developers of the application. It should definitely not be the role of the distribution's package maintainers. They just cannot maintain the packages of all softwares.
However, I understand that oni's maintainers have other priorities and might want to be consistent on the deployment strategy. It is effectively not that simple to decide to publish the application on a specific package manager and this needs reflection.
Hope still that someone from the community can help to have a draft version for oni in nix!
Hope still that someone from the community can help to have a draft version for oni in nix!
NixOS/nixpkgs#136101. I guess it soon will be included into unstable.
To me, deploying an application is part of the development lifecycle, and therefore is the responsibility of developers of the application. It should definitely not be the role of the distribution's package maintainers. They just cannot maintain the packages of all softwares. However, I understand that oni's maintainers have other priorities and might want to be consistent on the deployment strategy. It is effectively not that simple to decide to publish the application on a specific package manager and this needs reflection. Hope still that someone from the community can help to have a draft version for oni in nix!
True to some extent, but realize that oni2 does not consist of a large group of developers. The fact that the source code and build instructions are readily available, including a universal app package for those who doesn’t want to build from sources makes it a complete app in terms of a software development lifecycle.
Anyone interested in building distribution specific packages can do so. It is almost impossible for anyone, to maintain a dozen different package manager formats, in today’s fragmented world. As you use Nix as an example, Nix is an absurdly complex piece of software, perhaps on a similar order of magnitude as maybe Kubernetes or other gizmos, requiring a very large time commitment to understand and to use properly.
As a sidenote, I can mention that there are at least 15 different package managers in active use, and they all believe that they are the best solution and at least 10 claims to be able to coexist on any distribution.
(revery, ocaml, esy and all the jazz)
Most of the jazz is rolled up inside Nix. The tools used for creating oni2 is not to blame.
The only drawback at the moment is that this AppImage is not distributed publicly. One needs a license key to be able to download the file.
Understand that oni2 is still not released as stable, and is intended to be an open source, paid editor, so OSS, not free as in beer FOSS. Alpha builds in the AppImage format, are available for users who have pre-ordered via the Early Access Portal
You can still use the source packages for writing a Nix package or any other format, build instructions are provided.
@bryphe What is this doing here, anyway? Either decide on making support for 10+ packages a priority (goodbye life), or close it.
Either decide on making support for 10+ packages a priority (goodbye life), or close it.
I think of issues as a general way to inform the community and developers what should be done. To show the interest on the subject. The issue can be later resolved by third-party contributors. That's exactly our case.
I think of issues as a general way to inform the community and developers what should be done. To show the interest on the subject. The issue can be later resolved by third-party contributors. That's exactly our case.
I think of issues as something I'm having an issue with, as in a problem with. I can't see how this should be a problem related to the development of oni2. To please everyone is far from being a core responsibility of a developer. Resources would be wisely spent fixing actual issues relating to getting oni2 into a working condition.
I think of issues as something I'm having an issue with, as in a problem with. I can't see how this should be a problem related to the development of oni2. To please everyone is far from being a core responsibility of a developer.
Please recheck labels of the current issue and their descriptions. Labels themselves and their descriptions were created and added by Oni2's developers in the first place.
It clearly states that: a) This is an "enhancement". b) This issue requires help of community to resolve.
High-priority issues have another labels.
I think of issues as something I'm having an issue with, as in a problem with. I can't see how this should be a problem related to the development of oni2. To please everyone is far from being a core responsibility of a developer.
Please recheck labels of the current issue and their descriptions. Labels themselves and their descriptions were created and added by Oni2's developers in the first place.
Yeah, the labels read: We request help for implementing a new feature in the area of packaging (platform specific) An "Enhancement" implies a new feature / request. So, I ask, is this a sane strategy?
Yeah, the labels read: We request help for implementing a new feature in the area of packaging (platform specific) So, I ask, is this a sane strategy?
I don't see what's your problem. Issues are meant for everyone to look and anyone to resolve. The strategy of "help by 3-rd party contributors wanted" is adopted throughout the entire GitHub. Issues are not made only for actual contributors.
@gardspirito I don't have a problem with it, I just think that it isn't worth including every issue related to maybe 10-12 package managers into the oni2 repository. This will eventually be the case, and some seem to believe that the developer of a software application also has responsibility for keeping |n| number of distro-specific or platform-specific compiled packages up to date. But as you say, not my problem, really.
I initially created this issue to show interest in having oni built into Nix. I personally think Nix is a robust package manager, but that's only my opinion.
Maybe I am wrong, but to me, issues exist to report bugs, as well to convey a need/idea from the community.
Maintainers can totally decide this need is not aligned with the immediate goals of the project and close the issue. They can also think it is valid, but only if tackled by the community as there is no time to be spent for it by the maintainers themselves.
I never said it was the responsibility to core developers to develop and maintain the package for all existing package managers. What I said is that deployment/packaging is part of the development lifecycle. So developers should choose by which means they are willing to package and deliver their application to the end users. This can be again a simple binary, an appimage or a build recipe for one or many package managers.
My point again here is to defend that Nix is worth it. One can disagree and that's totally fine if there are counter arguments.
I just think that it isn't worth including every issue related to maybe 10-12 package managers into the oni2 repository.
I think about the opposite. It is worth having an issue for each package manager as it shows the interest of the community for each of them. And this could guide the core team to decide where to publish. An application is nothing if people cannot install it easily.
And to come back to Nix, I know that the prebuilt image is for people that contributed financially. And that's why we cannot create a public package out of it in Nix. However, I am really looking forward to the ongoing PR that aims to build from sources.
I personally think Nix is a robust package manager, but that's only my opinion.
Actually, I've heard others claiming so as well. They live and breathe Nix and sometimes NixOS, and are very emotional about it! :1st_place_medal: :)
I'm not saying Nix is bad. Far from it. Nix is a very promising project but that's also what it is IMO, a promising project.
I, personally, wouldn't swap out Debian Stable + Apt for it just jet. At least not for critical servers...
Hey, @bryphe: how about creating an oni2_editor.deb while you're at it!? Joking...
Unfree version of Oni2 has been merged into Nixpkgs Unstable.
Note that Hydra, obviously, does not perform building of unfree packages, and therefore installing oni2 from Nixpkgs will force local build.
https://github.com/NixOS/nixpkgs/pull/136101
progress through channels: https://nixpk.gs/pr-tracker.html?pr=136101
It should show up in search.nixos.org after it reaches nixos-unstable
https://search.nixos.org/packages?channel=unstable&query=oni2
