Drupal 10, the latest version of the open-source digital experience platform with even more features, is here.I have not been able to determine if this is supported, but I think not at this point.
I want to download the fckeditor or simplepie library (not using the libraries api). FCKEditor for example needs to be extracted into sites/all/modules/fckeditor/fckeditor which is already a directory that exists (it is precreated in module directory). So with the following library config
; FCKEditor Library
libraries[fckeditorlib][download][type] = get
libraries[fckeditorlib][download][url] = http://downloads.sourceforge.net/project/fckeditor/FCKeditor/2.6.5/FCKeditor_2.6.5.tar.gz
libraries[fckeditorlib][destination] = modules/fckeditor
libraries[fckeditorlib][directory_name] = fckeditor
libraries[fckeditorlib][install_path] = sites/all
fckeditorlib downloaded from [ok]
http://downloads.sourceforge.net/project/fckeditor/FCKeditor/2.6.5/FCKeditor_2.6.5.tar.gz.
Directory not empty: fckeditor/ [error]
I'm cool making a patch, but I'm just not sure if there is already a way to handle this. If not, how might you want it implemented?
| Comment | File | Size | Author |
|---|---|---|---|
| #13 | drush-make-copy-file-628198-13.patch | 2.61 KB | febbraro |
| #6 | drush-make-copy-file-628198-6.patch | 1.41 KB | febbraro |
| #2 | drush-make-copy-file-628198-2.patch | 1.51 KB | febbraro |
Comments
Comment #1
dmitrig01 CreditAttribution: dmitrig01 commentedremove the is_dir :-)
Comment #2
febbraro CreditAttribution: febbraro commentedThis patch allows you to additionally specify which specific files to move from the library into your destination with the copy_file key (very similar to how patch works)
Below are 3 specific examples from the project I'm building to highlight the use cases.
Case 1: Move all files into a directory that already exists.
Case 2: Move one file into a directory that already exists
Case 3: Copy the download to directory within a module
Comment #3
febbraro CreditAttribution: febbraro commentedFixing version, etc.
Comment #4
dmitrig01 CreditAttribution: dmitrig01 commentedMakes sense,
1) can we use something besides glob()?
2) why do you need to define install_path?
3) can we merge destination and directory_name?
4) it should be copy_files or probably just copy
5) this won't delete the original one will it? it should (i.e. download into folder X, move everything that matches $copy from folder X to folder Y, and delete folder X)
Comment #5
febbraro CreditAttribution: febbraro commentedThanks for the feedback.
1) Why not use glob? It allows for simplistic use of * for wildcarding of files. Is there something specific that glob does that we are trying to avoid? We could get a list of all files (recursively) and then use fnmatch() but that seems like a lot of work.
2) I have to define install_path b/c this is a .make file included in my distro (OpenPublish) and my main make file just specifies Drupal and openpublish, then after openpublish is downloaded this snippet is executed and if we do not specify install_path everything winds up in the profiles/openpublish directory (I guess that is the context) Is there a way around that? I would rather not have to specify it for each of my 50+ modules too.
3) I was just following what I thought was the correct mechanism based on the current code and examples. I am pretty sure it works either way, but we can test. Do you want to get rid of that generally for move too?
4) Yeah, I agree. I think 'copy' is best.
5) Do you think this is this because we are moving files out of within directory X instead of actually moving directory X? If so, yes I think you are right.
Once I hear back on the above I'll rework the patch.
Comment #6
febbraro CreditAttribution: febbraro commentedOk here is an update to that patch. Changes included are:
#3) We no longer use directory_name. We don't need to. Great observation (makes the code MUCH cleaner too). destination now specifies the full path to location if we are copying files.
#4) copy is now the new key in the .make file
#5) It now also properly cleans up the downloaded library on a copy when it is done.
Thanks for the review.
This is now what I'm using to stretch it's legs
Comment #7
dmitrig01 CreditAttribution: dmitrig01 commentedmodules might want to do this for whatever reason. can we change the main makePath function?
Comment #8
dmitrig01 CreditAttribution: dmitrig01 commentedAlso, this is pretty insecure. What if a rogue makefile included the copy string ../../../../../../../../../../../../../.. - it would try to copy / into that directory, and i'm not going to tell you what happens becuase I don't want to try.
Comment #9
febbraro CreditAttribution: febbraro commentedWill update the patch so that all can enjoy. Yes I do agree though, there is some inherent insecurities. The same exist surrounding install_path as well, no? We should probably create another issue to address those.
Comment #10
dmitrig01 CreditAttribution: dmitrig01 commentedOk. Try drush_make_validate_path.
Comment #11
dmitrig01 CreditAttribution: dmitrig01 commentedComment #12
univate CreditAttribution: univate commentedA module that I am having a similar issue with is the mp3player module.
The installation instructions ask you to copy two files from the downloaded zip package to a specific location in the module directory. It would obvious be great if modules could support having their libraries exist in a configurable path like the sites/all/libraries directory, but for the moment this 'copy' operation would come in real handy.
As for the security issue raised in #8 I don't really see this as a major issue or even a real security issue, as make files are intended to run internally and are not publicly accessible. As with any scripts / application or source you download you need to trust the source you are getting it from.
Comment #13
febbraro CreditAttribution: febbraro commentedOk, this patch moves the copy functionality up to DrushMakeProject so more folks can take advantage of it.
It does not do anything about the security concerns mentioned above. I think those need to be dealt with more generally in a different issue since it seems like it is a problem not just with copying files for libraries but with modules, themes, etc. as well.
Comment #14
dmitrig01 CreditAttribution: dmitrig01 commentedIt has been dealt with. Use drush_make_validate_path.
Comment #15
febbraro CreditAttribution: febbraro commentedWhere is that function? I don't see it anywhere in the drush_make codebase.
Comment #16
febbraro CreditAttribution: febbraro commentedComment #17
dmitrig01 CreditAttribution: dmitrig01 commentedshould be in .utilities.inc
Comment #18
thebuckst0p CreditAttribution: thebuckst0p commentedI'd like to expand this from libraries to projects:
[subdir] = customshould download a module to sites/all/modules/custom even if sites and sites/all already exists. (Currently it creates sites/sites if sites already exists, which doesn't make sense to me.) Is the current behavior a bug or intentional, and if the latter, I'm curious what is the reasoning?I'm trying to use Drush Make to combine a standard "common platform" (used on many sites) with custom code (for each site), and it's hard to do that when the root has to be essentially blank for Drush Make to work.
Please let me know if i'm missing something here, thanks!
Comment #19
wik CreditAttribution: wik commentedsubscribing
Comment #20
febbraro CreditAttribution: febbraro commentedSorry for the lack of progress here.
@dmitrig01 there is no function called drush_make_validate_path in drush_make.utilities.inc (or in any file in this project). Are you possibly referring to a function by a different name or in a different project?
Comment #21
dmitrig01 CreditAttribution: dmitrig01 commentedSorry, I meant drush_make_safe_path. http://drupalcode.org/viewvc/drupal/contributions/modules/drush_make/dru...
Comment #22
dmitrig01 CreditAttribution: dmitrig01 commentedWe're not going to support broken modules. If you can't get them working with drush_make, file an issue to integrate with http://drupal.org/project/libraries
Comment #23
KarenS CreditAttribution: KarenS commentedI'm looking for a way to delete some directories (or only copy specific ones). I found #656946: Provide Delete option which was marked as a duplicate of this issue, and then this issue was marked "won't fix". Does that mean you have no intention of providing a way to selectively copy or delete files?
Comment #24
febbraro CreditAttribution: febbraro commentedI agree with the "won't fix" and pushing modules towards using the libraries module. (I don't agree that modules NOT using the libraries module are broken though)
I do think that drush make should have some support for executing your own scripts, then you could do anything you want (like delete files, selective copying, etc.)