Looking for help packaging a Rust application

I’m looking for professional help to get the process started on packaging software in Rust / Cargo.

The end game would be something like:

  • Creating an initial snapcraft.yaml and adopt to some initial use-cases.
  • Create the needed CI/CD in github.
  • Assist in setting up a release strategy which would be following the github-repo eventually.

Let me know if you have some experience with this and I’ll be happy to follow up on details.

3 Likes

Currently I have 3/4 packages snapped written in rust. You can follow them.

Or, I can help you if you want.

1 Like

I’ve got something that works. But I’m stuck at the moment where I don’t know how to introduce “startup parameters” to my snap: How to make a file end up in /etc/default/polkadot

It has sucked up two days of my time to get here. Its painful.

Any advice on how to control the upstart of my snap such as they can be changed ?

system-files interface maybe! I cannot make helps, without understanding what and how your app works.

1 Like

I just want to be able to start the polkadot application/service with command line parameters from the file /etc/default/polkadot

Its ok if the file is in a similar location in the snap given that it can be updated by an admin.

Till I am confused, but correct me if I am saying wrong. What you simply want to do is create/start an app/part of an app from outside of that snap, and here trying that from your snap. This thing is not possible. That is how confinement works. I am sorry, if I understood it wrong. Or may be it’s out of my capabilities.

No. I simply want to be able to start the application like:

“systemctl start polkadot.service”

But I need to be able to alter the startup parameters as part of the systemd unit file:s which typically can read startup parameters from an environment file - like - /etc/default/polkadot

A system admin should be able to change the content of that file /etc/default/polkadot - such as for example change startup parameters.

How would a user otherwise be able to alter the startup parameters other than defined in the snap build?

These topics are sensitive, and rather related to the structure to the snapd. I hope @ogra can help you with more details on this.

I mean - why on earth would I like to ship a complex software as a snap if it can’t be configured by an admin?

I’m totally cool with not being able to configure it from /etc/default/polkadot on the host OS. But I mean - how does other configure snapped services for runtime?

chatGPT gave me this response to:

“how would I implement support for altering startup parameters for a service shipped with a snap ?”

I’ll try this…

To implement support for altering startup parameters for a service shipped with a snap, you can follow these steps:

  1. Create a configuration file: In your snap project, create a configuration file where users can specify the startup parameters for the service. For example, you can create a file named service-args in the root directory of your project.

  2. Include the configuration file in the snap: Update your snapcraft.yaml file to include the configuration file in the snap. You can use the files attribute to specify the source and destination paths. For example:

...
parts:
  your-part:
    # Snapcraft part configuration

apps:
  your-app:
    command: bin/start-service.sh $SNAP_DATA/service-args
    ...
    plugs:
      - home
      - read
      - write
      - ...
    environment:
      SNAP_DATA: $SNAP_DATA
...

# Copy the configuration file to the appropriate location in the snap
parts:
  your-part:
    ...
    files:
      - service-args: $SNAPCRAFT_PART_INSTALL/service-args

In this example, we include the service-args file as part of the your-part in the snap. We also reference the service-args file in the command attribute of the your-app section.

  1. Read the configuration file in the service startup script: Modify your service startup script (start-service.sh in this example) to read the configuration file and use its contents as the startup parameters for the service. You can use standard file reading techniques in the scripting language of your choice.

Here’s an example of how the start-service.sh script could read the configuration file and pass the parameters:

#!/bin/sh

# Read the configuration file
SERVICE_ARGS_FILE="$SNAP_DATA/service-args"
SERVICE_ARGS=$(cat "$SERVICE_ARGS_FILE")

# Start the service with the specified parameters
/bin/polkadot $SERVICE_ARGS

In this example, the script reads the contents of the service-args file into the SERVICE_ARGS variable and then starts the service (polkadot binary) with the specified parameters.

  1. Build and install the snap: Build the snap using snapcraft and install it on your system.

  2. Modify the configuration file: After installation, users can modify the service-args file located in the SNAP_DATA directory (e.g., /var/snap/your-snap-name/current/service-args) to change the startup parameters of the service.

By following these steps, users can modify the service-args file to define the desired startup parameters for the service shipped with the snap. The service startup script will read the contents of the file and start the service with the specified parameters when the snap is run.

Please note that modifying files within the snap’s installed directory, such as the configuration file, typically requires appropriate snap interfaces and permissions (plugs) to be defined in the snapcraft.yaml file. Make sure to include the necessary interfaces to allow read and write access to the configuration file, such as home, read, write, etc., based on your specific requirements.

Okay, so, if you can do this. You can use your custom wrapper, to start your app, or for anything. Just the snap should have the permission, when installed from the store. I am sorry, but this was started as a general support request for packaging rust based apps. I am sorry, I don’t have such indepth knowledge. I am extremely sorry about that.

1 Like

No worries, I appreciate your efforts. Thanx alot.

In the end I spent a few days trying to understand what I could do. The documentation around the rust plugin is close to zero, so there was almost 100% trial and error to get to where I am now.

This is my snap now:

The experience was horrible - primarily because of lack of any useful documentation and examples. Like almost nothing in my snap uses elements from the documentation, but comes mostly from chatGPT and me trial and error.

@degville

1 Like