-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[RFC] Dependency Management #8555
Comments
That is not possible with our current code to load JS files into templates, where we need t load it from
Then we also need to force this upon all apps the can be installed from the appstore, no? |
cc @rullzer @blizzz @schiessle @nickvergessen Opinions? |
The full list of JS dependencies should be https://github.com/nextcloud/server/blob/master/bower.json and the full list of PHP dependencies should be https://github.com/nextcloud/3rdparty/blob/master/composer.json
|
Unfortunately the mentioned composer/bower files are not complete: The PHP composer.json lacks declaration of bundled deps of deps (see below, e.g. DBAL is bundled but provides another 6 bundled (php-doctrine) libs). For JS, some bower.json files are not complete, and some apps lack such file altogether or they have been removed at some point (e.g. see this commit on the comments app). The same goes for non-existent LICENSE information on some JS libs (also comments app)
Not all JS deps are in a
That would seem preferable to me, yes. During dependency analysis I came up with this list (taken from my rpm spec). Note that for the PHP libraries, I only looked at the deps of the bundled libs that weren't in the Fedora repos, so I had to bundle them in the rpm (interersting here DBAL and sabre/dav). There is a NOTE for each dep not listed in a bower.json:
I would appreciate a review of this list. Also note that I only looke at vendored libs that come with the main deliverable (the one that includes core and the "standard" apps, including gallery), but not at any other apps that need to be downloaded from the app store. Edit: The list of Licenses I came up with is: |
Do you then bundle the exact same version of the libs? And also be aware that we put some patches in those libs: https://github.com/nextcloud/3rdparty/blob/master/patches.txt I hope this is then okay? |
For Fedora, I only bundle the js libs and the patched php libs (excluding the patched Zipstreamer lib, which is packaged seperately). All other PHP libs are in the Fedora distro in their required version. This is not necessarily the exact version that is bundled here, see: |
We only guarantee that it works with the exact versions. Often we have workarounds in place for specific versions because the lib hasn't released a new version. So this could break the overall system in some cases. :/ I really appreciate your work, but we had people from distributions in the past, that did exactly this (especially Adam from Fedora IIRC) and then gave up, because building a web app is a lot harder then the usual libs and applications on an OS and the neverending update cycles with updated dependency versions and stuff like that are simply not suited to be taken out of the release we do. I don't want to de-motivate you, but rather prepare you to this hard endeavor. Using just our tar ball and distribute that in a package is the safer approach and also what we test extensively. Also this would allow to track bugs here and not do this on your side as well. Because if you bundle Nextcloud with different versions of the lib we can not guarantee anything and the users then need to test again with our version. Also keep in mind, that an update typically also involve a maintenance step (calling |
@MorrisJobke thanks for the heads up. NC13 is my entry point to this story. I will make sure there's an upgrade path from here on out (>13). Personally, I will not support upgrading from any version below it, as I've never used them. (PRs on the RPM are of course welcome!) |
Maybe also have a look at the ownCloud packages: https://build.opensuse.org/project/show/isv:ownCloud:community They maybe give you some hint on how it was done. They were pretty stable - not perfect, but worked. Maybe it helps you. The Nextcloud project just dropped the work on this, because it was a huge amount of time that went into this with still some rough parts. So we decided to only provide the tar balls and a built-in updater. But back to the original point: We would be happy if you update the license list in the repos. @schiessle What is your opinion here, do we need this from a legal point? (I don't think so, because the license is listed for every dependency on it's own anyways) And should we somehow automatically compile this list from composer? cc @rullzer |
Unfortunately, not all deps come with their license info (see, e.g. At.js and Caret.js in comments app). |
Another thought: |
My new proposal (see PRs referenced above) includes suggestion of a few rules for future app development:
|
I think this should be reflected in the bower/composer files by removing the ^ and ~ before the versions in order to specify an exact version. Thoughts? |
Makes a lot of sense to pin the exact version. cc @icewind1991 @rullzer @schiessle @blizzz @nickvergessen |
Pinning the versions is good. I'm not a big fan of the |
The files are supposed to also include info about patches, gathering all dep info in one place. However, if all package/bower/composer files were in fact kept up to date (or even existed), maybe we wouldn't need them. |
@MorrisJobke @rullzer @blizzz @schiessle @nickvergessen |
@LorbusChris any chance you'd be at the Nextcloud conf? A face to face would make this conversation easier, perhaps ;-) |
@jospoortvliet I'll be there Thu - Sun! |
As we discussed this at the conference it's a tricky topic. I would like to not do it for now as it basically adds a lot of maintenance work for not much outcome. Sorry for this. I hope that's okay for you. |
I noticed a few things when deving on nextcloud-rpm:
vendor
vs3rdparty
: There is no consistent naming of the vendor dirs inapps/
. Sometimes JS deps are in a/js
dir, sometimes not:I propose to always put vendored libs in
<appname>/3rdparty
, regardless if its a JS or PHP lib. That way it'll be much easier to keep track of all bundled libraries.I also propose to replace
LICENSE INFO
with3RDPARTY_INFO
containing info about Licenses and Versions of the bundled libs in 3rdparty as well any Patches applied (and Links to their respective Upstream Issues). Do the same inapps/APPS_INFO
for any bundled libs in apps (that are shipped with core).If this is a welcome change, I will create a PR.
The text was updated successfully, but these errors were encountered: