Environment variables

doc
#8

Thanks for helping me understand a bit better.

But this still feels like a very jarring broken experience. I’m not going to say whether the fix would be to run the “adapter” script when running --shell or something else.

Do you think I should file this as an issue against snapd or snapcraft?

#9

This should no longer be a problem after you set the apps._app_name_.adapter property to full (which should be the default in future Snapcraft).

1 Like
#10

Ah so you’re saying this will soon work intuitively out of the box? Any idea when that might land?

#11

you’re saying this will soon work intuitively out of the box?

Well that’s what documented in the source comments, I have no idea when it will really be a thing.

1 Like
#12

Thanks for the heads up, I’ve updated the description.

1 Like
#13

Hello,

it may be just that I missed it, but I’m thinking I could use an env variable that provides a USER_DATA_PATH with the “current” snap revision ‘wildcard’ in it.

I would be using whatever it returns as a basis for constructing a default for a user-modifiable path setting in my app, that works across revisions of my snap.

(So I’d “typically” like to construct the

/home/username/snap/snapname/current/mystuffgoeshere/

path instead of the

/home/username/snap/snapname/x123/mystuffgoeshere/

since /home/username/snap/snapname/x123/mystuffgoeshere/ becomes inaccessible after a snap refresh, and the path should update to /home/username/snap/snapname/x124/mystuffgoeshere/, which then feels dodgy if done automagically)

and I guess I need

/home/username/snap/snapname/current/

as a basis. Is there an envrionment variable now to provide that? Is there a best practice to construct the value if not (I’ll likely do some string replacement for starters), and shouldn’t there be a variable/recipe?

Or is it just a stupid question, do such values pose a risk I didn’t spot at first?

Thank you!

#14

From the entry for SNAP_LIBRARY_PATH:

" The value is always /var/lib/snapd/lib/gl:"

For my test (hello-world) snap, it’s slightly more involved:

SNAP_LIBRARY_PATH=/var/lib/snapd/lib/gl:/var/lib/snapd/lib/gl32:/var/lib/snapd/void

Not sure if that distinction needs to be clarified.

#15

The inconsistency is due to the code change in the subsequent snapd releases, the content will likely not be stable and would need to be updated time-to-time.

We probably should just point to the source code where this variable is determined instead of duplicating them in the documents.

#16

That sounds reasonable.

#17

There’s a grammar mistake in SNAP_COMMON:

“Unlike SNAP_DATA this directory does is not backed up”

1 Like
#18

Fixed - thank you for letting us know!

1 Like
#19

It’s pretty cool to be able to list these environment variables, but how can we edit them? I want to pass a specific JAVA_HOME to gradle, but I have a hard time finding any information about this in the documentation…

#20

Thanks for asking this question. I’ll try to make this information easier to find, but you should be able to pass a specific JAVA_HOME using build-environment within the part, eg:

    plugin: gradle
    [...]
    build-environment:
      - JAVA_HOME: /usr/lib/jvm/java-11-openjdk-amd64

This behaviour is briefly discussed here:

Another useful tip is to search GitHub for projects trying to do the same thing: https://github.com/search?q=filename%3Asnapcraft.yaml+%22plugin%3A+gradle%22+%22JAVA_HOME%22&type=Code

1 Like
#21

@degville With snapd 2.57 a new variable has been introduced on ubuntu core systems.

SNAP_SAVE_DATA

Points to a snap-specific location on the ubuntu-save partition where the snap is allowed to store persistent files (like certificates or configuration files) which will survive a factory reset. The variable is only exposed on Ubuntu Core systems, and was introduced with snapd 2.57

2 Likes
#22

Thanks Philip! I’ve updated the doc to include your definition.

2 Likes
#23

I would like to improve the description of this environment variable as per Where to store config files but I can’t figure out the proper words, please help fix it.

This directory is suitable to store potentially backward-incompatible data as the data is backed up and restored across snap refresh and snap revert operations so the users can restore the application to its previous state even if the data breaks its newly released revisions.

#24

What do you think about this?

#25

I believe this part is incorrect as snapd only guarantees that if data incompatibility issues occur you can rollback to the previous working unmodified data and software(to the extent that the previous data hasn’t dropped by the rotation logic).

When a snap is refreshed the SNAP_USER_DATA of the previous snap revision gets duplicated to the new revision, not cleared.

#26

That’s true! What about this?

#27

The “This makes sure the older version of your application doesn’t use newer, backwards-incompatible, data.” part seems to be ambiguous IMO, how about the following instead:

1 Like