Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Livebook and its possible uses #369

Open
20 tasks
marcoherbst opened this issue Feb 12, 2024 · 17 comments
Open
20 tasks

Livebook and its possible uses #369

marcoherbst opened this issue Feb 12, 2024 · 17 comments
Assignees

Comments

@marcoherbst
Copy link
Member

marcoherbst commented Feb 12, 2024

Consider including https://livebook.dev/ as part of our package. (Or offering instructions for a user to do this themselves)

Some possible uses:

Superficially at least, it seems the livebook teams people believe this sort of thing is reasonable:

image

@marcoherbst marcoherbst changed the title Catchall issue for lots of small ideas (Placeholder) Consider including Livebook as part of our package. Feb 28, 2024
@marcoherbst marcoherbst changed the title Consider including Livebook as part of our package. Consider including Livebook as part of our package or offer self-install guidelines. Feb 28, 2024
@marcoherbst marcoherbst changed the title Consider including Livebook as part of our package or offer self-install guidelines. Include Livebook as part of our package or offer self-install guidelines. Feb 28, 2024
@marcoherbst marcoherbst added this to the v0.11.0 milestone Feb 28, 2024
@marcoherbst marcoherbst changed the title Include Livebook as part of our package or offer self-install guidelines. Livebook and its possibile benefits May 2, 2024
@marcoherbst marcoherbst changed the title Livebook and its possibile benefits Livebook and its possible usees May 11, 2024
@marcoherbst marcoherbst changed the title Livebook and its possible usees Livebook and its possible uses May 11, 2024
@marcoherbst marcoherbst removed this from the v0.11.0 milestone Jul 23, 2024
@the-prksh the-prksh self-assigned this Aug 8, 2024
@the-prksh
Copy link
Collaborator

the-prksh commented Aug 9, 2024

Hey 👋 ,

I am currently integrating livebook ~> 0.13.3 and I have encountered a problem with dependency resolution. Livebook depends on phoenix_live_view ~> 1.0.0-rc.5, while another project dependency, flop_phoenix, depends on phoenix_live_view ~> 0.20.4. flop_phoenix does not have upgrades available that support the required phoenix_live_view.

I am struggling to find a way to resolve this conflict. Can anyone provide some insight on how to address this issue?

I added the following lines to mix.exs in the deps function:

      {:livebook, "~> 0.13.2"},
      {:kino, "~> 0.13.2"},
      {:vega_lite, "~> 0.1"}

Here is the output of mix deps resolution:

. . .
Because your app depends on livebook ~> 0.13.2 which depends on phoenix_live_view 1.0.0-rc.5, phoenix_live_view 1.0.0-rc.5 is required.
So, because your app depends on phoenix_live_view ~> 0.20.0, version solving failed.

After upgrading the phoenix_live_view from 0.20.0 to 1.0.0-rc.5

. . .
Because flop_phoenix >= 0.22.7 depends on phoenix_live_view ~> 0.20.4 and flop_phoenix >= 0.21.2 and < 0.22.7 depends on phoenix_live_view ~> 0.19.0 or ~> 0.20.0, flop_phoenix >= 0.21.2 requires phoenix_live_view ~> 0.19.0 or ~> 0.20.0.
And because your app depends on flop_phoenix ~> 0.22, phoenix_live_view ~> 0.19.0 or ~> 0.20.0 is required.
So, because your app depends on phoenix_live_view ~> 1.0.0-rc.5, version solving failed.
** (Mix) Hex dependency resolution failed

@gBillal
Copy link
Member

gBillal commented Aug 10, 2024

I don't think including livebook as a dependency is a good idea. It's better to run a standalone livebook, creating the livebooks and connecting it to a running instance of ex_nvr to do the actual job.

If you still want to include it directly, either:

  • Upgrade the other dependencies to meet the requirements.
  • Or find an older version of livebook that doesn't cause conflicts with the actual dependencies.

@the-prksh
Copy link
Collaborator

the-prksh commented Aug 14, 2024

Running a standalone node locally and connecting it to a running instance of ex_nvr on a Raspberry Pi is not possible because ex_nvr runs on Elixir 1.15, while for Livebook the node must run Erlang/OTP 26 and Elixir 1.16.3 (or later).

Either elixir or deps needs to be upgraded.

Here's a screenshot for reference:

Screen Shot 2024-08-14 at 3 49 41 PM

@gBillal
Copy link
Member

gBillal commented Aug 14, 2024

Unfortunately we cannot upgrade elixir to the latest version on ex_nvr for legacy reasons. However you can downgrade livebook to meet the requirements.

@the-prksh
Copy link
Collaborator

May I know the legacy reasons?

I have upgraded the Elixir version in the Dockerfile to hexpm/elixir:1.17.2-erlang-27.0-alpine-3.18.7 and everything seems to be working fine.

@the-prksh
Copy link
Collaborator

the-prksh commented Aug 16, 2024

I have deployed and checked in Raspberry Pi as well, and it is working fine there as well.

@gBillal Would you like to have a look?

@the-prksh
Copy link
Collaborator

the-prksh commented Aug 16, 2024

When it comes to the Standalone livebook node in local machine and connecting runtime with edge device,

It won't function on edge devices because the device doesn't have mix installed. Due to this, we are unable to install dependencies dynamically using Mix.install/1.

You might be curious about how nerves_livebook addresses this issue. They tackle it by including all the livebook related dependencies as part of the release image and tweaking the Mix.install/1 functionality. Here is the code for that - https://github.com/nerves-livebook/nerves_livebook/blob/main/lib/nerves_livebook/mix_install.ex

Screen Shot 2024-08-16 at 3 57 45 PM

@marcoherbst
Copy link
Member Author

Do I understand correctly, that to use Livebook on a Pi, any dependencies would have to have been included in the firmware build?

Is that true only if we were using nerves? (which at the moment we're not), or is this some other limitation related to a Pi that even with a regular OS (Debian, PiOS), Mix cannot be used?

@the-prksh
Copy link
Collaborator

the-prksh commented Aug 19, 2024

It is true when integrating using an Attached Node or Embedded Mode, but only partially true when integrating using a Standalone Node.

It has nothing to do with nerves. The Pi OS will be trimmed compared to a regular OS. In our case, the Production release of ex_nvr will not contain Mix and other development dependencies.

This blog contains the difference between an Attached node and a Standalone node. https://news.livebook.dev/remote-execution-smart-cell---launch-week-2---day-1-m3dv2

I said partially true because in Standalone node, The livebook node will run on the local machine and connect to the ex_nvr node. The notebook's dependencies will be installed on the local machine. It will use erpc to call functions of ex_nvr. However, it will not work with hardware functionalities such as Pi's peripherals, WiFi configurations, etc. To enable this functionality, an API needs to be developed in the firmware or the related dependencies should be added as part of the ex_nvr release.

@the-prksh
Copy link
Collaborator

I prefer using embedded mode. Nerves has used this approach to integrate Livebook. All dependencies will be included in the ex_nvr release, so there's no need to install anything on your local machine. Just use the link to open Livebook.

@gBillal
Copy link
Member

gBillal commented Aug 19, 2024

Hi
The legacy reasons I'm talking about is that we're using devices (rasberry pi) with old debian versions. If we use Elixir 1.17.x to create the releases it'll include dependencies that'll not work on old versions (however an old version works fine on newer versions).

For livebook with attached mode, you cannot install dependencies, however you can do the following:

  • Include the dependencies you need in exnvr itself and then use attached mode in livebook
  • Or use smart cell (remote execution) to only get the data you need from exnvr and then use the livebook runtime to process that data. In this case you can use System.cmd or System.shell to execute commands on the remote machine (e.g. turn on/off wifi)

@the-prksh
Copy link
Collaborator

Hello @gBillal ,

Are you saying that some of the production kits contain old Debian versions that may cause issues?

We are not changing the Debian version, only upgrading the Elixir/Erlang version. So, I don't think there would be any issue in that case. Is there any way we can test that?

Also, in attached mode, atleast elixir >= 1.16 is required.

@the-prksh
Copy link
Collaborator

  • Or use smart cell (remote execution) to only get the data you need from exnvr and then use the livebook runtime to process that data. In this case you can use System.cmd or System.shell to execute commands on the remote machine (e.g. turn on/off wifi)

This will be possible in "Standalone Mode", but for that, a livebook has to be set up on the laptop. @marcoherbst explained that he expects to integrate the livebook into the ex_nvr dashboard. This will not be possible if we go with Standalone Mode.

@gBillal
Copy link
Member

gBillal commented Aug 19, 2024

We are not changing the Debian version, only upgrading the Elixir/Erlang version. So, I don't think there would be any issue in that case. Is there any way we can test that?

Elixir 1.17 docker images are all based on the newer debian version and if that image is used to build arm64 releases, the external dependencies (like ex_dtls, libsrtp2, ..) will depend on newer version of GLIBC which will not be loaded on old version of debian. I already tested this.

Anyway you can work on a new branch, upgrade elixir and any dependencies you need and create a release from there. Unfortunately we cannot upgrade right now.

@the-prksh
Copy link
Collaborator

the-prksh commented Aug 19, 2024

@gBillal Is it possible to upgrade Elixir to version 1.16 in that case? or Can you share the Debian version?

@gBillal
Copy link
Member

gBillal commented Aug 20, 2024

As I said above, this work won't make it to the main branch. So you're free to work on a branch, upgrade to any version and create a release from there where we can test it on some devices.

we'll upgrade Elixir once we're no longer using old raspbian version on our side.

@marcoherbst
Copy link
Member Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants