Hi!
Since it isn't possible to use the drupal packaging system för external libraries, we still need to figure out a painless way to get the additional files. There's currently a nodestream.make file in profiles/nodestream folder in the bundle you download. Since the bundle already contains drupal and all the contrib modules, the only thing that's left to do is to download the external projects and the patches, which the makefile does.
However, the make file currently includes the make file that has already been ran by drupal.org, making the drush make command taking longer because it downloads all the stuff again.
I believe the intention of the nodestream.make file was to just run the file and get everything. However that won't work if you don't check out the intallation from CVS and then places it in the profiles folder which isn't straightforward.
My proposal:
* Remove the inclusion of the drupal.org makefile
* Remove the downloading of drupal core.
Then the installation instructions are quite easy:
* Download the bundle from the project page.
* run drush make profiles/nodestream/nodestream.make from the drupal directory.
All the files are there and you can proceed with the installation as usual.
The attached patch removes the inclusion of the drupal make script and removes the fetching of drupal core. It also changes the README.txt slightly to better describe how to install. It also fixes a typo =)
| Comment | File | Size | Author |
|---|---|---|---|
| #1 | nodestream-install-workflow.patch | 693 bytes | fabsor |
| nodestream-install-workflow.patch | 1.16 KB | fabsor |
Comments
Comment #1
fabsor commentedThis was actually wrong. I thought that the packaging script actually packaged the contributed modules into the packages which obviously was a wrong assumption. We still need to fix the documentation though. Here's a patch that just updates README.txt. The project page should probably be updated as well.
Comment #2
dixon_Drupal.org is packaging the profile with core and all contrib modules. But they are placed a little bit strange in
profiles/nodestream/modules/modules/. I consider that as a bug in the packaging script. But it works for now.One of our outstanding goals is to be fully compatible with the packaging system here on d.o. It's important to be able to just download the complete package directly from the project page and then install it. So I rather see us removing features from NodeStream, just to be compatible. From the top of my head I see the WYSIWYG and jQuery UI features being the biggest problem, as they are third party libraries that are not compatible with the packaging policy.
Comment #3
fabsor commentedWe could bundle Jquery UI with the profile, since it is GPL v2.
TinyMCE is a bit of a problem since all code distributed through drupal.org is considered gpl v2, and TinyMCE is LGPL, but we could at least get around the jquery UI part of the problem, and maybe choose a different wysiwyg editor.
Comment #4
fabsor commentedOn further investigation, it seems that CKEditor is licensed under GPL v2, as long as you provide a file named LEGAL in it, specifically stating this. Maybe an option?
Comment #5
dixon_Any WYSIWYG-editor must be placed in
sites/all/librariesin order to work withwysiwyg.module. And the jQuery UI library must be placed inside the jquery_ui module folder. And because both of these required paths are outside the profile folder, there is not much we can do about it. The packaging script won't let you download any third party libraries at all (even though they might be GPL).Anyway, I've now striped out the WYSIWYG-support from the profile. That solution with Exportable + Input formats + WYSIWYG + this patch was very messy any way. Input formats was never designed to be exportable and is better left as is.
However, I found a solution for the jQuery UI problem. During the install process I managed to implement a solution where modules dependent on the library never is installed if the library is missing. It now degrades gracefully instead of throwing database errors during install. So if downloading directly from d.o without manually putting the library in place, everything will work fine, except some cool UI features.
Comment #6
stattler commentedToday after downloading the package and running the nodestream.make file, I see that it fetches drupal tar file also.
When I try to install nodestream, it just installs default drupal. However, when I install from the package (without running make file), it installs okay. It shows me an option "to install NodeStream" at the beginning. Then I get a themed drupal installed.
Why is this difference?
Comment #7
dixon_The reason for this is probably that you are compiling it the wrong way with drush make. Here is what you have to do:
1. Download the profile only package here from d.o (found here: http://drupal.org/node/891490/release)
2. Go to your web root (maybe
/var/www/public_html) and create a folder calledprofilesand extract the profile there.3. You now have a path looking like this:
/var/www/public_html/profiles/nodestream/nodestream.make4. Stand in
/var/www/public_html/and run:drush make profiles/nodestream/nodestream.make.This will build the package the correct way for you. We will provide better documentation on this soon.
Comment #8
brunodboThe steps outlined in #7 worked great for me. Perhaps it would be handy to add these to the project page, so people find them there?