[Feature request] Make apio installation a single step process

[zapta]

Currently apio installation includes multiple steps

1. Python instllation
2. Apio pip package installation
3. Apio packages installation.
4. Install homebrew (on Mac osx, for ftdi drivers)

This feature request is for making it a single step process. For example, by running a script or program that will do the rest of the installation.

BTW, we have feature request #517 to eliminate #2 using automatic on-demand apio package instllation.

[zapta]

Note to self. One option is to use pyinstaller one-folder mode (the one-file mode would be too slow for the fequent invocations of apio).

https://pyinstaller.org/en/stable/operating-mode.html#how-the-one-folder-program-works

We should check also what installer icestudio does. @cavearr, any thoughts on an installer for apio that includes the python interpreter and all the other requirements?

[cavearr]

Hello @zapta, I tell you how I see it, from Icestudio it is not that much of a problem to install Apio because since the installation is managed from Icestudio it does not matter the number of steps to be carried out since everything is simplified for the user.

In Icestudio I am changing things that I will soon make operational during the installation, for example I want the user to be able to use their own python environment if they have it installed or in the development version I want to eliminate the need to have git installed (possibly I will create preleases or directly packages that can be downloaded and decompressed from Apio).

For these reasons, at Icestudio it is not critical to further simplify the installation.

Looking at Apio independently, I would not abandon the pip format since in the end the problem with bundlers is that they take up a lot, if for each python application, all python was packaged... I don't know in that sense I'm not very pro bundlers. But it's my way of seeing it and for newer users it may be attractive to install in a single step.

I also tell you that an installer could be made via script per operating system that would do the entire process and could be called from the command line with a curl call to a url that would download and execute the script.

For example, I don't like the Icestudio bundler system for Linux since it happens a bit the same as before, all the bundlers like snap, flatimage, etc. for me are an overload of resources and I know that today the price of the mega hard drive is very cheap but at least it bothers me to feel that I have the same thing installed in multiple packages.

If I had to choose a package manager that seems very interesting to me in the long term, it is Nix, it is cross-platform and works really well.

I was helping a group of Nix packagers this summer to package Icestudio (for now only for Linux and Windows), I didn't know Nix well until then and I thought it was amazing.

[zh4ngx]

NixOS user here and I second the idea of using Nix Packages :)

I ran into an issue where I can't use an FTDI device due to having to modify udev rules, considered immutable in Nix.

Filed the issue here: #534

[zapta]

I see two terms here, NixOS and Nix Packages.  

1. In apio's terms, is NixOS a new platform in addition to these ones?  https://github.com/FPGAwars/apio/blob/develop/apio/resources/platforms.json

2. Does the nix packager support all the other platforms on that list?

3. What will be the steps of installing apio using Nix packages on, let's say, a vanilla Windows machine?

I made a quick experiment with pyinstaller on darwin arm 64 and it seems promising, it created a 20MB zip file that includes an apio binary and a directory called _internal that includes the support files, including the python interpreter and packages I think (?)

Anybody want to give it a try? Zip below, unzip on a Mac OSX apple silicon and add the apio binary to your path.

apio-release.zip

EDIT: (updated zip file) After unzipping, read README.txt in the unzipped directory and run source activate. Then, set your PATH to include the directory and use the apio command. The first run may be slower than usual.

[cavearr]

Hi @zapta! i'm using nix for some packages(not nixos as operating system, nix as package manager) and this is great, is multiplatform and very powerful.

With Icestudio we have nix packages for linux , in osx we have problems (almost for the official packages in nix) i have a PR open but goes slowly and windows i don't know the state of this. Last summer i was in contact with the maintainers and try to help them with it: https://mynixos.com/nixpkgs/package/icestudio

I'm not an expert in nix but we could research around it and how we could create a repository for our nix packages and could be our future packager for Apio and Icestudio

I'll try your package in osx and works well, for windows or linux we need to create that packagers.

If you want i could create the architecture for our own nix channel , i think could be a very great idea. If you want i invest time in it.

[zh4ngx]

@zapta

The answers to your Qs to the best of my understanding:

1. No, NixOS is more like a Linux distro (eg Debian, Fedora) but does not use the Unix FHS.
2. Nix packages (nixpkgs) does run on all of those platforms, but definitely double-check my claim here. Packages built in nixpkgs try to follow NixOS conventions, adapted to the particular platform. For example, on non-NixOS Linux, you can run nixpkgs alongside the FHS, but nixpkgs will will never make any FHS assumptions out-of-the-box.
3. I'm not super familiar with nixpkgs on Windows, but I set up nixpkgs, both on Fedora and NixOS, using this guide. It has a WSL section, which is what I assume you're using for apio.
   If you use the Determinate installer:

curl --proto '=https' --tlsv1.2 -sSf -L https://install.determinate.systems/nix | sh -s -- install

You should be able to run a nix shell with apio installed like so:

nix shell nixpkgs#apio nixpkgs#libftdi nixpkgs#gtkwave

Let me know if you run into any issues. You may see something related to "nix flakes," although the Determinate installer is supposed to set that up for you.

[zapta]

Thanks Any, I will look into it. My concern is that we will require the user to install an intrusive package management system just to use an app. It's kind of "the tail wagging the dog" situation.

[zh4ngx]

Totally get it. The practice I've seen some packages adopt is to make nix the gold standard and then adapt it to other package managers, but those packages often start as nix-first. In your situation, you would likely do the opposite; see what is working in other package managers and try do simplify / do it better in nixpkgs. Then you can backport some of those practices to other package managers. nixpkgs/NixOS is often more restrictive than other package managers / distros. Most backports involve sandboxing changes made to the environment. For example, the nix shell ... you see there doesn't actually install anything in the global env.

It doesn't look like apio is too far off from being able to accomplish this. The main issues I see are udev rules and the assumption that services exists - more discussion in the issue.