Default path for projects, libraries [#911722]

Comment	File	Size	Author
#35	drush-make-default-project-path-911722-5473410.patch	2.52 KB	boztek
#34	drush-default-project-path-911722-3925286.patch	2.09 KB	boztek

Comment #1

TN, USA

commented 14 September 2010 at 23:48

Correction, the --contrib-destination argument moves *all* downloads to the specified directory by default, so the only way of doing it right now it to manually specify the [subdir] argument for all projects. Ew.

Log in or register to post comments

Comment #2

rjmackay commented 6 October 2010 at 14:43

subscribing

Log in or register to post comments

Comment #3

dmitrig01 commented 7 October 2010 at 02:52

Status:

Active

» Closed (duplicate)

#913148: Please bring back install_path

Log in or register to post comments

Comment #4

damienmckenna

TN, USA

commented 8 October 2010 at 12:55

Status:

Closed (duplicate)

» Active

The other issue is not strictly the same as this request, so this ticket is being reopened.

Log in or register to post comments

Comment #5

dmitrig01 commented 9 October 2010 at 01:16

whoops, you're right.

In the .ini format, which .info is based off of, you have something like this.

[section]
subection = 1
subsection2 = 2

[section2]
somethingelse = 52

Which would be able to very nicely solve our problem. However, that format's not really an option. THe only thing that comes to mind is some sort of hack like

subdir = contrib
projects[] = foo
projects[] = bar
subdir = custom
projects[] = baz

for which we'd need to re-write the .info parser anyway, but a hack is a hack. The really tricky thing is we run into issues like this one:

[contrib]
project[foo][bar] = test
[custom]
project[foo][baz] = asdf

where do we put foo? under contrib or custom?

Log in or register to post comments

Comment #6

guddomeNt commented 11 November 2010 at 08:56

The syntax doesn't really cater for it currently, but I think it would be helpful to somehow use a scope for this, rather than a global setting. Eg. semantically something like:

scope {
  subdir = "contrib"
  projects[] = foo
  projects[] = bar
}

I realise that this will derive the syntax from .info files, so I'm not sure if the trade is worth it.

Log in or register to post comments

Comment #7

dmitrig01 commented 11 November 2010 at 18:48

I think changing the syntax is fine - but again, you'd run into the problem I had in comment #5.

But, we could do something like this as a shortcut:

(subdir = "contrib", location = "http://code.developmentseed.org/fserver") {
  projects[] = foo
  projects[] = bar
}

Log in or register to post comments

Comment #8

dmitrig01 commented 11 November 2010 at 18:57

A side note, while we're talking about this - it'd be great if there was a more concise array notation, f.e.

projects[foo][download] = (type = "get",  url = "http://example.com/example.tgz")

Or extrapolated to

projects[foo] = (download = (type = "get",  url = "http://example.com/example.tgz"))

Though, that's not very pretty - but, while we're looking at enhancing the syntax, I'd like to consider something like this.

Log in or register to post comments

Comment #9

damienmckenna

TN, USA

commented 11 November 2010 at 19:17

An alternative method of handling this would be to just add an option to create the "sites/all/modules/contrib" directory, because if it exists then Drush automatically downloads modules to there.

Log in or register to post comments

Comment #10

dmitrig01 commented 11 November 2010 at 23:11

yes, though drush make doesn't use drush dl's logic, and as such doesn't automatically download to sites/all/modules/contrib

Log in or register to post comments

Comment #11

damienmckenna

TN, USA

commented 11 November 2010 at 23:13

@dmitrig01: .. maybe it should where appropriate, e.g. this case?

Log in or register to post comments

Comment #12

guddomeNt commented 12 November 2010 at 00:00

I'm not sure I understand what you mean by ".. the problem I had in comment #5 .."?

Consider this:

scope {
  subdir = "contrib"
  projects[] = foo
  projects[] = bar
}
projects[] = baz

Which would be semantically synonymous with this:

projects[foo][subdir] = "contrib"
projects[bar][subdir] = "contrib"
projects[] = baz

Since "baz" is outside the scope, it isn't affected by the "subdir" setting. No need for any parenthesis there.

Note that I don't particularly like the syntax I proposed. Perhaps something like this would be more elegant:

projects:
    admin:
        subdir: contrib
        version: 2.0
    admin_language:
        subdir: contrib
        version: 1.4

group:
    subdir: contrib
    projects:
        foo
        bar

Log in or register to post comments

Comment #13

dmitrig01 commented 12 November 2010 at 00:35

Yep. To recap, my syntax:

(subdir = "contrib", location = "http://code.developmentseed.org/fserver") {
  projects[] = foo
  projects[] = bar
}

Which is the same as

projects[foo][subdir] = "contrib"
projects[foo][subdir] = "http://code.developmentseed.org/fserver"
projects[bar][subdir] = "contrib"
projects[bar][location] = "http://code.developmentseed.org/fserver"

I prefer my syntax because:
1. The scope { syntax is confusing, because you're doin a lot of hardcoding in there, and what if someone were to write this?

scope {
  projects[] = foo
  subdir = "contrib"
}

2. The second, almost YAML-like format is also not preferable IMO because first, it falls under the same problem as #1, and 2, an .info/.ini-based format is closer to what most people are familiar with (as in, PHP) - [] is used for arrays, and {} is used for nesting. The parenthesis in my example is similar to a function declaration, but it declares specifically _what_ the scope is.

It's also easily nestable:

(subdir = "contrib") {
  projects[] = foo
  (location = "http://code.developmentseed.org/fserver") {
    projects[] = bar
  }
}

should be fairly understandable - both foo and bar have subdir = contrib, but only bar has the modified location = code.developmentseed.org...

Log in or register to post comments

Comment #14

dmitrig01 commented 12 November 2010 at 00:41

Also, when I referred to comment #5, I meant the following problem.
Using your syntax:

scope {
  subdir = "contrib"
  projects[foo][a] = 1
}
scope {
  subdir = "custom"
  projects[foo][b] = 1
}

Now, under what subdir does projects[foo] fall (yes, one could say either the first or last, but how will most people who don't rtfm know)? However, I've since realized that we probably could just throw an error in this situation (i.e., setting attributes in different scopes). So, disregard that issue, and let's continue discussing the syntax itself - I'd like to hear any cons you have about my syntax.

Log in or register to post comments

Comment #15

damienmckenna

TN, USA

commented 12 November 2010 at 02:52

An alternative syntax idea.

Attributes (subdir, location) are taken for all relevant definitions (project, etc), e.g.:
```
subdir = "contrib"
project[] = "cck"
project[] = "views"
```

Repeated attributes override the previous setting for that attribute, e.g.:

subdir = "contrib"
project[] = "cck" ; goes in sites/all/modules/contrib/cck
project[] = "views" ; goes in sites/all/modules/contrib/views
subdir = "custom"
location = "http://example.com/fserver"
project[] = "funkychicken" ; goes in sites/all/modules/custom/monkeychicken, loaded from example.com/fserver
location = "http://example2.com/fserver"
project[] = "monkeychicken" ; goes in sites/all/modules/custom/monkeychicken, loaded from example2.com/fserver

The attribute value "default" reverts to the default setting for that attribute, e.g.:

subdir = "contrib"
project[] = "cck" ; goes in sites/all/modules/contrib/cck
project[] = "views" ; goes in sites/all/modules/contrib/views
subdir = "custom"
location = "http://example.com/fserver"
project[] = "funkychicken" ; goes in sites/all/modules/custom/monkeychicken, loaded from example.com/fserver
location = "http://example2.com/fserver"
project[] = "monkeychicken" ; goes in sites/all/modules/custom/monkeychicken, loaded from example2.com/fserver
subdir = "default"
project[] = "curriedchicken" ; goes in sites/all/modules/curriedchicken, loaded from example2.com/fserver

The key rationale for suggesting this was to avoid adding more syntax hacks.

Log in or register to post comments

Comment #16

dmitrig01 commented 12 November 2010 at 02:57

That is an interesting idea, but I see two problems with this:

The first is that it needs the hardcoded of "subdir means this inherits, project means it doesn't inherit", etc - what if we introduce a new property? Do we have to update the index of inheritable properties?

Also, a lesser problem, what if you wanted something to go in sites/all/modules/default?

To me, this solution seems to be a bit less elegant - it seems simply to try to massage the existing syntax into something that could work, but to me, just doesn't feel completely "correct."

What do you think of the syntax in #13 - would that work? What I like about it is that a makes a distinction between properties that should be set (those are in the parenthesis) and info definitions themselves (which stay the same).

Log in or register to post comments

Comment #17

damienmckenna

TN, USA

commented 12 November 2010 at 03:10

@dmitrig01: you make valid points. Could the syntax from #13 be done without the extra brackets, e.g.:

subdir = "contrib" {
  projects[] = foo
  location = "http://code.developmentseed.org/fserver" {
    projects[] = bar
  }
}

Log in or register to post comments

Comment #18

dmitrig01 commented 12 November 2010 at 03:34

sure. i just thought it made it a little bit easier to read and separated out, especially with multiple:

(subdir = "contrib", location = "http://code.developmentseed.org/fserver") {
  projects[] = foo
  projects[] = bar
}

Log in or register to post comments

Comment #19

damienmckenna

TN, USA

commented 12 November 2010 at 03:52

Maybe make the parenthesis required for multiple terms but have it optional for single terms?

Log in or register to post comments

Comment #20

dmitrig01 commented 12 November 2010 at 04:07

Maybe. but that still could create some confusion if written oddly

projects[] = foo
subdir = custom
{
projects[] = bar
}

Not to mention that it would be easier for a parser if it had ().

Log in or register to post comments

Comment #21

dmitrig01 commented 12 November 2010 at 04:18

[edit: double post]

Log in or register to post comments

Comment #22

dmitrig01 commented 12 November 2010 at 04:19

Also of note: my proposed format (especially as opposed to #12) is fully backwards-compatible

Log in or register to post comments

Comment #23

dmitrig01 commented 12 November 2010 at 07:32

Status:

Active

» Postponed

I'm going to mark this "postponed" as this is something I'd like to see in 3.x, but to get 2.0 out the door I don't think writing a new grammar parser is feasible.

Log in or register to post comments

Comment #24

dmitrig01 commented 12 November 2010 at 07:32

However, let's continue the discussion - I am looking forward to implementing this and we might as well straighten out all the details beforehand.

Log in or register to post comments

Comment #25

winston commented 3 January 2011 at 04:40

Not 100% sure this is related, but fishing through the issue queue led me here.

I would like to be able to download files using drush make as well. For example download an archive an have it placed in a files folder (or some other arbitrary folder either under sites or under the drupal root).

In my specific use case this would be to provide demo snapshots, but I could foresee other uses.

Log in or register to post comments

Comment #26

sime

any/any

Melbourne

commented 10 January 2011 at 03:44

Feels like some of the ideas are over-worked and the syntax being suggested seriously reduces the readability of the make file (one of the makefile's strengths IMO). There is no additional functionality being introduced here, just the desire to simplify the make file and make it more readable and maintainable.

defaults[subdir] = contrib

;Put this module and 30 or so others in whatever the default is.
projects[] = views	
projects[] = ctools	

;Put this *one* module in an alternative location. Usually there are not many.
projects[adhoc][subdir] = custom

Alternatively, the OP raises the idea of a generic solution for setting default arguments (which can be overridden on CLI):

; Default --contrib-destination
default_arguments[contrib-destination] = sites/all/modules/contrib
; Default --working-copy
default_arguments[working-copy] = TRUE

Log in or register to post comments

Comment #27

dmitrig01 commented 6 February 2011 at 17:38

Status:

Postponed

» Fixed

Log in or register to post comments

Comment #28

20 February 2011 at 17:40

Status:

Fixed

» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Log in or register to post comments

Comment #29

damienmckenna

TN, USA

commented 1 November 2011 at 01:38

Was this closed prematurely, or is there another way of doing this? Thanks.

Log in or register to post comments

Comment #30

dtwork commented 2 November 2011 at 17:05

Status:

Closed (fixed)

» Active

can 'fixed' be further explained? what's the solution?

Log in or register to post comments

Comment #31

dtwork commented 5 November 2011 at 14:34

Version:

6.x-2.0-beta9

» 6.x-2.x-dev

Log in or register to post comments

Comment #32

dtwork commented 10 November 2011 at 20:47

Bueller?... Bueller?... Bueller?

Log in or register to post comments

Comment #33

helmo commented 15 December 2011 at 20:31

Project:	Drush Make	» Drush
Version:	6.x-2.x-dev	»
Component:	Code	» Make

[ Powered by #1115636: Issue Macros and Templates - Drush Make]

Drush make is being merged into drush core (discussed in issue:#1310130: Put drush make in drush core)
This means that the issue queue is also moving. The drush queue has a component 'Make' especially for drush_make.

More information will be posted on the drush_make and drush project pages.

Log in or register to post comments

Comment #34

boztek commented 16 January 2012 at 05:31

Status	File	Size
new	drush-default-project-path-911722-3925286.patch	2.09 KB

I agree a simple solution where a default can be set either as a command line option or in a defaults array would be a useful first step.

Here is a patch with both a 'default-subdir' option and a defaults[subdir] make file option as sketched by sime in #26.

Log in or register to post comments

Comment #35

boztek commented 16 January 2012 at 12:06

Status:

Active

» Needs review

Status	File	Size
new	drush-make-default-project-path-911722-5473410.patch	2.52 KB

Updated comment.

Log in or register to post comments

Comment #36

dmitrig01 commented 19 January 2012 at 17:13

Sorry, what I meant when I fixed this issue was I fixed it in the 3.x version, using notation similar to what I outlined in #13, with all kinds of additional crazyness. However, that was not ported to Drush core -- only 2.x was. So this functionality got lost in 'the void'. I don't have time to port this forward, but if someone would like to take it up, I think it shouldn't be too difficult but it would be a major improvement.

Log in or register to post comments

Comment #37

moshe weitzman commented 9 February 2012 at 02:47

Status:

Needs review

» Postponed (maintainer needs more info)

It is possible that this lower priority now that we are integrated with pm-download. please add current summary if needed.

Log in or register to post comments

Comment #38

jonhattan

Spanish

Plasencia

commented 7 July 2012 at 16:37

Status:

Postponed (maintainer needs more info)

» Closed (duplicate)

Another solution was recently commited in #1633050: Create defaults array in .make files for specifying attributes common to all projects. So marking this as duplicate. Reopen for further discussion.

The approach is simpler than proposals in this issue:

core = "7.x"
api = 2

defaults[projects][subdir] = contrib
projects[] = ctools

Log in or register to post comments

Default path for projects, libraries

Comments