The install file is not being included in drush downloads or direct zip/gzip downloads of the project, versions 7.x.1.x amd 7.x.2.x. However, it is present in the repository itself when cloned via git, in both 7.x.1.x and 7.x.2.x.

➜ ~/trashhh wget http://ftp.drupal.org/files/projects/composer_manager-7.x-1.7.tar.gz
--2015-08-31 11:42:04--  http://ftp.drupal.org/files/projects/composer_manager-7.x-1.7.tar.gz
Resolving ftp.drupal.org... 23.235.46.68
Connecting to ftp.drupal.org|23.235.46.68|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 20839 (20K) [application/octet-stream]
Saving to: 'composer_manager-7.x-1.7.tar.gz'

composer_manager-7.x-1.7.tar.gz              100%[===============================================================================================>]  20.35K  --.-KB/s   in 0.06s

2015-08-31 11:42:05 (329 KB/s) - 'composer_manager-7.x-1.7.tar.gz' saved [20839/20839]

➜ ~/trashhh tar zxf composer_manager-7.x-1.7.tar.gz
➜ ~/trashhh ls -l composer_manager/composer_manager.install
ls: composer_manager/composer_manager.install: No such file or directory
➜ ~/trashhh ls -l */*.install
fish: No matches for wildcard '*/*.install'.
ls -l */*.install
      ^
➜ ~/trashhh ls -l composer_manager
total 184
-rw-r--r--  1 greggles  staff  18092 Sep 23  2014 LICENSE.txt
-rw-r--r--  1 greggles  staff  14911 Sep 28  2014 README.md
-rw-r--r--  1 greggles  staff    779 Sep 28  2014 composer.json
-rw-r--r--  1 greggles  staff  13208 Sep 28  2014 composer_manager.admin.inc
-rw-r--r--  1 greggles  staff    606 Sep 28  2014 composer_manager.api.php
-rw-r--r--  1 greggles  staff   5049 Sep 28  2014 composer_manager.drush.inc
-rw-r--r--  1 greggles  staff    399 Sep 28  2014 composer_manager.info
-rw-r--r--  1 greggles  staff   7139 Sep 28  2014 composer_manager.module
-rw-r--r--  1 greggles  staff  10059 Sep 28  2014 composer_manager.writer.inc
➜ ~/trashhh
➜ ~/trashhh cd ~/checkouts/composer_manager/
➜ ~/c/composer_manager git:(7.x-1.x) git checkout 7.x-1.7
Note: checking out '7.x-1.7'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 6181dc5... Issue #2340759 by nhoag: Respect composer_manager_vendor_dir value from settings.php on install.
➜ ~/c/composer_manager ls -l composer_manager.install
ls: composer_manager.install: No such file or directory
➜ ~/c/composer_manager

Comments

jcmiller09 created an issue. See original summary.

jcmiller09’s picture

jcmiller09 CreditAttribution: jcmiller09 commented

The current dev version actually does have the .install file present when downloaded as a file, and with drush download.

jcmiller09’s picture

jcmiller09 CreditAttribution: jcmiller09 commented
Issue summary: View changes

typo

greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles at CARD.com commented
Issue summary: View changes
greggles’s picture

greggles
he/him
Primary language English
Location Denver, Colorado, USA
CreditAttribution: greggles at CARD.com commented
Issue summary: View changes

Sorry, this was supposed to be my comment, not part of the issue summary:

I agree with the analysis, but think that it was purposefully removed for the 7.x-1.7 release (not sure if that was a good idea or not, but at least the packaging system is not broken).

jcmiller09’s picture

jcmiller09 CreditAttribution: jcmiller09 commented

That's good to know! I think the bigger issue is that disabling the module leaves some entries in the variable table, and those values are still picked up by the composer_manager_file_dir function in composer_manager.writer.inc, line 246 which looks for file_default_scheme().
$dir_uri = variable_get('composer_manager_file_dir', file_default_scheme() . '://composer');

Specifically in my case, I use amazons3 to manage local files, so I got stuck in a chicken and egg loop, where the composer manager needs to grab the dependencies for the Amazon S3 module, but is still looking for the value set there previously (the wrapper and folder s3://composer) so I was getting nowhere fast. Maybe keep the install file in the project with some queries to remove the variables table rows and remove the calls to the variable table?

If the install file is still in the dev version, what does that indicate, that it's part of the module again? Or was it just removed by mistake?

deviantintegral’s picture

deviantintegral CreditAttribution: deviantintegral at Lullabot commented

It looks like this was caught over at https://www.drupal.org/node/2340759#comment-9226893. I'm working on a 7.x-1.8 release today that includes the restored install file. If you need to uninstall the module now, I'd upgrade to the dev release and then uninstall it.

deviantintegral’s picture

deviantintegral CreditAttribution: deviantintegral at Lullabot commented
Status: Active » Fixed

This is fixed in 7.x-1.8: https://www.drupal.org/node/2604922

Status: Fixed » Closed (fixed)

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