Server: RFE: an option to install nextcloud via php composer

[muayyad-alsadi]

nextcloud already use composer.json
so why not use it to distribute nextcloud (just an option beside docker and distros rpm/deb, need not be the option)

why this is important?

• because users would be able to consume nextcloud directly from upstream without relying on lagging distros packgers
• it would use php's native package manager that is already used.
• allow users to upgrade easily
• more developer friendly
• more OPs options ex. php internal server, apache, nginx, php-fpm, uWSGI, ...etc.
• better for automation
• more 12 factor

examples

wordpress

roots/bedrock have produced a 12 factor wordpress that can be installed up and running with one command

composer create-project roots/bedrock your-project-folder-name

Yii Advanced App Template

Yii's advanced App installed using the following command

composer create-project --prefer-dist yiisoft/yii2-app-advanced yii-application

What need to be done ?

• your vendor is configured to be lib/composer, I believe it should be empty and git-ignored like this
• 3rd-party should not be git sub-mobule, they should be fetched using composer, composer features like version-locked files () and one can easily setup a local mirror for composer using satis

[anassahmed]

The 3rd-party directory part would also be beneficial for RPM packages as they remove all these libraries because they're packaged elsewhere and not bundled with the official package. 😉

[MorrisJobke]

Thanks for this request.

We thought a lot about distribution channels in the past and settled on: do only one thing and this properly. So we focused on the way to distribute the release of Nextcloud via archives and built the updater around this concept. Also we have a bit longer build script that does for example the signing process, etc to have a verified package or to fetch in other shipped apps from other repos.

All of this makes it harder to ship it via composer. Also the docker and RPMs are fully community driven. If somebody steps up to provide Nextcloud via composer: feel free to do so, but in my opinion distributing a end user software via a tool that was designed to manage libraries and dependencies feels a bit odd.

I hope this gives some insight. I will close this ticket for now as we have it not on our roadmap to provide this, but as written: if somebody wants to take care of it we are happy to assist.

Thanks

[EvilBMP]

All of this makes it harder to ship it via composer. Also the docker and RPMs are fully community driven. If somebody steps up to provide Nextcloud via composer: feel free to do so, but in my opinion distributing a end user software via a tool that was designed to manage libraries and dependencies feels a bit odd.

@MorrisJobke
I think, nextcloud is not only distributed as end user software. If agencies use nextcloud together with other client web software they want to distribute it via shell and put the(ir) stuff under version control.

In my opinion, distributing software only via ZIP files, feels a bit "aged".

[MorrisJobke]

In my opinion, distributing software only via ZIP files, feels a bit "aged".

The thing with "providing ways to distribute software" is, that it basically eats resources on our side. We are good in developing software - so we try to spend as much time with this. We want to have a software that just works and solves the problems we want to solve. There are a huge amount of ways to distribute software - just to name a few RPM, DEB, snap, docker, composer, flatpak, appimage, brew, nix packages, ansible cookbook, chef recipes ... I guess you get the idea. We want to provide the basic release and we do this as a zip archive. There is also nothing bad about a zip archive. In this way distributors can pick up this zip and bundle it in a way they want.

[muayyad-alsadi]

when I opened this ticket, my intention is not to throw the maintenance of another distribution channel (composer) on your resources.

composer do support VCS like GIT
to get it I might just use a snippet like this

    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/nextcloud/server.git"
        }
    ],
    "require": {
        "nextcloud/server": "*"
    }
}

in other words there is no extra effort or "maintenance" or "resources" needed. your team already use git and already use composer.

but there are so many bad practices that your team to need to give up (ex. like having a copy of dependencies in same git repo)

your team has to be educated with 12 factor, it's a culture that has to be enforced and it's not only for the sake of supporting composer, it's for the good of the project maintainability and health.

instead of copying dependences you need to declare them in a git ignored way (composer lock is your friend), if you need to deploy them as is from an archive, you might create a git submodule or use phar ..etc.

you need to be a ware of the problem that make you violate best practices
you need to need to find proper solutions to those problems.
once those are done, the community might pickup and create composer-based installer like they did with wordpress-installer

[MorrisJobke]

but there are so many bad practices that your team to need to give up (ex. like having a copy of dependencies in same git repo)

We do this actually on purpose. And we are also well aware of the 12 factor principles. Also composer.lock files are known. But we also want to accomplish other goals beside that - like total independence from repository failures when packagist or npm is down. It's not that we are uneducated or people that ignore useful techniques. We actually thought a lot about all of this. There are long discussions about this here in the bug tracker if we should drop our 3rdparty repo completely and only depend on composer.lock.

Unfortunately there is not this single way of accomplishing all our requirements and thus we have chosen a way in between. Also this repo is not the only source for building a release. There are other repos fetched in that we actually don't want to have in here as submodules and thus are hard to integrate in the "composer way" of deploying software.

Thus we came to the conclusion to provide exactly one official way of getting our software: releases in the form of an archive on our download servers. Those can be used by many many tools out there to then deploy it in the way the administrator want it - be it vanilla, docker, snap, appliance as VM, chef, puppet, salt, ...

We try to make it better with every release but changing this way completely is out of scope because there are better ways to spend our time: actually fixing bugs and working on the product.

I hope you can understand this.

[muayyad-alsadi]

like total independence from repository failures when packagist or npm is down.

your are not the first one to need this and for sure there are many solutions

in python they have wheel directory (which serves as a repo)

$ pip wheel --wheel-dir=/tmp/wheelhouse SomePackage
$ pip install --no-index --find-links=/tmp/wheelhouse SomePackage

--no-index tells pip to work offline and --find-links tells it to use directory as repo

in node I was told about npm cache and yarn
in php composer they have satis

of course there are other methods

Unfortunately there is not this single way of accomplishing all our requirements and thus we have chosen a way in between.

would you do those hacks in a git submodule or a different git repo? and keep your default git repo "clean" from deployment hacks

quote from 12 factor build release run

The twelve-factor app uses strict separation between the build, release, and run stages.

currently your git repo holds the build result not the pure code
now you need to work a method to build that code into an re-distributable offline build
my guess satis and phar can solve this