iMac-di-Raffaele-Filomena:magento raffaele$ curl -s -L https://raw.github.com/colinmollenhour/modman/master/modman-installer

!/usr/bin/env bash

if [ ! -d "$HOME/bin" ] ; then mkdir $HOME/bin

if [ -f $HOME/.profile ]; then
    tty -s && . $HOME/.profile

    if [[ ":$PATH:" != *":$HOME/bin:"* ]]; then
        echo -e '\nPATH="$HOME/bin:$PATH"' >> $HOME/.profile
    fi
fi

fi

SRC="https://raw.githubusercontent.com/colinmollenhour/modman/master/modman" DEST="$HOME/bin/modman"

test if curl/wget is installed

if hash curl 2>&- ; then CMD="curl -s -L $SRC -o $DEST" elif hash wget 2>&- ; then CMD="wget -q --no-check-certificate -O $DEST $SRC" else echo "You need to have curl or wget installed." exit 1 fi

$CMD

chmod +x $DEST

echo "Done. Modman installed in $HOME/bin/modman"

where is dir installation? thanks

After applying this commit, modules will be added and removed from a newly-created .repos file inside the .modman directory. This file is intended to be committed to the super-repository, and is roughly equivalent to the lock file in Composer.

This is only really relevant if you're working on a site from more than one location, which is often the case when you're working in a multi-user environment.

A new Magento patch (SUPEE-9767 released yesterday, May 31 2017) suggests that you should disable Symlinks setting before applying the patch:

Before applying the patch or upgrading to the latest release, make sure to disable Symlinks setting [...] The setting, if enabled, will override configuration file setting and changing it will require direct database modification.

If you are managing modules by modman that use template files, these will not work as described in modman's README. I guess the reason for the suggestion of disabling Symlinks setting is the APPSEC-1281: Remote code execution through symlinks fix included in the patch.

How will this affect modman? If you need to have Symlinks setting enabled to use modman (if you do not want to patch Mage/Core/Block/Template.php as suggested in modman's README), this means your Magento shop is opened for at least one known security threat...

I've recently been reading a lot of articles about using .modman alongside composer to manage project dependencies. One thing that grates on me slightly is the fact that in these workflows the "vendor" modules sit in the same directory as the "project specific" code. This leaves you in a situation where you have committed code in the same directory as vendor code, which is not ideal. To draw a parallel this feels like having the src directory sitting in the vendor directory in a Symfony 2 project.

The only way I can think of getting around this would require modman supporting the ability to install from (at least 2) different directories. This would allow project specific code to be committed / tracked in .modman and composer to deploy magento modules to .modman-vendor (or perhaps vice-versa as this may be simpler to achieve without modification to current tools such as AOEpeople/composer-installers).

I'm thinking we could add a --modman-dir option, allowing the developer to optionally specify from which directory they wish to modman commands to operate. I've not thought about this in too much depth as I wanted to check your receptiveness to the idea first, however I believe implementation will largely be replacing any reference to .modman with a variable set at the top of the script. If the option is specified, current behaviour is completely unmodified, if it is, all commands are based against the specified directory.

Modman does not create an entry in the .gitmodules file when installing a module. As a result you can no longer update other git submodules in the parent repo.

When executing the git submodule update command: > git submodule update --init --recursive You get the following error: No submodule mapping found in .gitmodules for path '.modman/Cm_Cache_Backend_Redis'

When installing the Cm_Cache_Backend_Redis module: > modman clone git://github.com/colinmollenhour/Cm_Cache_Backend_Redis.git

I would expect to find the following entry in the .gitmodules file of the parent repo:

[submodule "Cm_Cache_Backend_Redis"]
path = .modman/Cm_Cache_Backend_Redis
url = git://github.com/colinmollenhour/Cm_Cache_Backend_Redis.git

I have added these lines manually for now but I am not sure if this will cause problems further down the track.

@colinmollenhour

Great way to manage my Magento code ! :100: I just couldn't find how to use modeman to link and unlink the modules.

I mean like install and remove them using modman :)

Thanks,

@gayanhewa

Specifying --modmandir allows control over where modman will place / source code from. Effectively allowing multiple modman directories for a single install. Refs #87.

Is it possible to provide a functionality like "undeploy-all" and "remove-all" in regards to the existing function deploy-all?

Thanks!

Installer as mentioned in modman page is not working. Both wget and curl commands say modman is installed, but the created directory is emply. I also used source command.

Now I used a sh file copy & paste from here https://github.com/zerium/modman/blob/c52bde6c341e7bec59ab187a92d98ffa40862802/modman-installer

It is not working too. How can I install modman???

Hi,

I would really like to use modman on a Mittwald Managed Server. Unfortunately, I get the following error when running deploy-all: ./module-manager/modman: Zeile 631: /dev/fd/62: Datei oder Verzeichnis nicht gefunden ("File or Directory not found")

Mittwald told me that modman only works with access to /proc and that this access is not available on their systems. Is it possible to use modman without it?

Thanks a lot for all your work! Cheers, Simon

It seems the relative symbolic links that are made are one level too deep.

Instead of ../../../../.modman/my/files/here (four levels up), it should be ../../../.modman/my/files/here.

I tried the version @Caprico85 has and I was able to get the right amount. However, my symlinks still aren't working. For some reason, even though the path in the symlink is good, it doesn't work.

I tried to figure out if the path was wrong by going to the symlink's folder and manually creating the symlink but not even autocompletion allows me to pull up my module's folder under the .modman folder. I'm able to use tab completion up to that point. The name of my module doesn't contain any special characters. I looked to see if maybe it was a folder permission error but it doesn't appear to be. Anyone else having these issues?

Modman is relying on a lot of loose behaviors in bash, which appears to be the source of many bugs.

Using potentially unbound variables in a script that alters the filesystem is dangerous and unacceptable.

The script needs to be put into strict mode to protect against this.

Furthermore, if a subcommand fails with an unexpected non-zero exit code, the entire script needs to halt.

At the top of the script:

set -eu

Modman parsing of command line arguments and options is contrived in inextricable ways and documentation is of no help. Two cases:

1. For the 'deploy' command, --modmandir option works if and only if it is put between 'deploy' and module name, it won't have any effects otherwise. The right syntax is modman deploy --modmandir <path> <module> <options>
2. For the 'link' command, help states the syntax link <path> so one is induced in thinking that module source path should be put before immediately after the command and before all the following arguments, as per the module command syntax: modman <command> [<module>] [<options>] [[--] <VCS options>], but again no: path is actually an additional argument to be put after the module name and before options, and help does not give any hint for this. Here we are with modman link <module> <path> <options>

Tried on version 1.12 and using options --force and --copy.

So if I start typing:

modman update Vend

I can get the autocomplete to give me:

modman update Vendor_Module

However if I type:

modman update --copy --force Vend

The autocomplete doesn't work anymore.

It would be nice to have a configuration file where you could set default behavior for: no-local, no-clean, no-shell, basedir, copy for all or only specific modules.

Hi, when working with modman we often see this for every country/locale subdirectory that we have. They are symlinked dirs to a different folder. Is there any way of preventing the below?

Can we change something? Or learn modman to exclude thesse dirs?

[server]$ modman remove package find: ./nl/nl': Too many levels of symbolic links find:./nl/errors/errors': Too many levels of symbolic links find: `./nl/lib/lib': Too many levels of symbolic links