Open skjnldsv opened 1 year ago
see also: https://github.com/owncloud/core/pull/30889 it can be done also automatically at install time for new setups to encourage this
What if we move the shipped apps out and leave the good old apps for external apps?
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?
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
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 :shrug:
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
I will ask all the packagers (VM, docker, snap, ...) for feedback on this, so we take into account what they face
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.
That breaks offline installs. But as outlined above an app can exist in multiple dirs and the newest version is used
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.
installation as it may break existing appliances
Well, existing appliances do not go through the setup process :) So this should not be an issue
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
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.
We could hardcode the new directory without adding it to config.php
For the sake of my comment, let's say we're considering the following:
apps
directory to, say, released-apps
apps
directory to serve as the writable apps areaIt'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 :stuck_out_tongue: .
Following some discussions that I've seen happening in the past and recently too
Proposal
On every setup, dev AND prod, having a read-only and read-write apps folders should be the preferred and official way.
Reasoning
apps
, update goes intoapps2
Questions
apps2
?custom_apps
?cc @PVince81 @ChristophWurst @nickvergessen @blizzz @juliushaertl @icewind1991