Splitting shipped and installed apps about standards HOT 15 OPEN

What if we move the shipped apps out and leave the good old apps for external apps?

from standards.

That breaks offline installs. But as outlined above an app can exist in multiple dirs and the newest version is used

from standards.

see also: owncloud/core#30889
it can be done also automatically at install time for new setups to encourage this

from standards.

I think @ChristophWurst's proposal makes a lot of sense. Something like apps-shipped.

One thought regarding updating shipped apps via app store: Nextcloud whould have to always use the newest version of an app locally available, right? So if Text is shipped in apps-shipped as 1.2.3, then gets updated via app store to 1.2.4 in apps and then the shipped version in apps-shipped updates to 1.3.0, we should either remove the older version from apps automatically during the upgrade process, or disregard it when deciding with version to load.

The scenario of updating shipped apps via app store also is a good reason to not invent a new name for shipped apps in my opinion. Both are apps and both can be updated via app store. It's just that some of them are already shipped by default 🤷

from standards.

I'd vote for adding a setup warning if not at least two locations are provided.

That is exactly why we'd move the current shipped apps. That doesn't require any change on existing setups. It will automatically work out of the box, shipped code we can move as we want and doesn't need a writable folder. And the downloaded appstore apps stay where they are

from standards.

What if we move the shipped apps out and leave the good old apps for external apps?

I don't quite understand where out would be. Moving all the shipped apps into the main folder of server feels cluttered to me.

What about calling shipped apps components and having a components folder?

from standards.

Whatever the name is, this is what Christoph was suggestiong :)
Use apps as the default writable apps folder, and another one for what is shipped

from standards.

disregard it when deciding with version to load.

We already do that.
We take the bigger version number and use it.
We fixed it a few versions ago (22 or 23 iirc) :)

We cannot update/delete folders of shipped apps, it will cause integrity errors unfortunately

from standards.

I will ask all the packagers (VM, docker, snap, ...) for feedback on this, so we take into account what they face

from standards.

We cannot update/delete folders of shipped apps, it will cause integrity errors unfortunately

What about the other way around? No shipped versions, but those will be installed during installation.
Then every app is "only" an app via app store.

from standards.

I'd vote for adding a setup warning if not at least two locations are provided. However I would not enforce it during the installation as it may break existing appliances.

from standards.

installation as it may break existing appliances

Well, existing appliances do not go through the setup process :)
So this should not be an issue

from standards.

Snap packager here. First of all: big fan of the idea. It's how we've shipped Nextcloud from the beginning: leaving the shipped apps read-only in the <webroot>/apps directory, and adding a writable extra-apps folder elsewhere.

What would be the apps folder name ? apps2 ? custom_apps ?

Initially, I agreed with @ChristophWurst's proposal: leave the apps folder as the writable area, and move the apps bundled with the Nextcloud release elsewhere (release-apps, maybe). That said, that kind of change would break existing configs where folks are already using this kind of setup, like the snap. The config we've been shipping for years has this:

// ...
'apps_paths' => array(
        /**
         * These are the default apps shipped with Nextcloud. They are read-only.
         */
        array(
                'path'=> $snap_current.'/htdocs/apps',
                'url' => '/apps',
                'writable' => false,
        ),

        /**
         * This directory is writable, meant for apps installed by the user.
         */
        array(
                'path'=> $snap_data_current.'/nextcloud/extra-apps',
                'url' => '/extra-apps',
                'writable' => true,
        ),
),
// ...

If you move/change the purpose of the apps folder, you will invalidate all those deployed configs. Patching a user's config in an update is a hairy, risky process that I'd prefer to avoid, personally. So I lean more toward a new extra-apps directory. Whatever we do, we need to keep existing deployments in mind.

from standards.

We could hardcode the new directory without adding it to config.php

from standards.

For the sake of my comment, let's say we're considering the following:

1. Move the existing apps directory to, say, released-apps
2. Create a new, empty apps directory to serve as the writable apps area

It's not entirely clear which one you're suggesting to hard-code (perhaps both), so I'll cover both here.

Speaking only from the snap perspective, I don't immediately see an issue with hard-coding read-only access to (1) onto the apps_paths (i.e. without requiring it to be in the config). We would need to handle possible conflicts there where e.g. a user might try to add released-apps to their apps_path with writable access, but I assume you have considered that and I will hereby consider it out of scope for this comment.

Hard-coding writable access to (2) onto the apps_paths would be problematic for the snap, though, because the entire webroot is completely read-only. There's no way to make that new apps directory writable as it's on a squashfs image. Also, we already have a config for the apps directory saying it's read-only, which brings me back to the conflict that I was hoping to ignore, but is rearing its head again 😛 .

from standards.