[FEATURE] Optional create 'typo3_src' as symlink instead download source

[dalder]

I am not that experienced with custom composer installers. But it could be used as a input to support symlinks instead of downloading the source to 'typo3_src'.

Adding a symlink target for typo3_src in your composer.json is possible as shown below:

"extra": {
  "source-as-symlink": "/var/lib/typo3/TYPO3_6-2/"
}

So it's possible to use global sources on your server.

[KampfCaspar]

Preventing possible name collisions, what would you think about prepending the key with e.g. 'typo3-'?

[lars85]

In my opinion this feature is not necessary..

Write

    "replace": {
            "typo3/cms": "*"
        },

into your htdocs/composer.json and create the symlink yourself..

ln -s /var/lib/typo3/TYPO3_6-2 typo3_src
ln -s typo3_src/index.php
ln -s typo3_src/typo3
git add . & ...

[fabarea]

:+1: for solving the symlink issue. We are facing the "problem" too.

@lars85 I tried your approach but it does not work for a new set up. I tried with this composer.json

{
  "repositories": [
    {
      "type": "composer",
      "url": "http://composer.typo3.org/"
    }
  ],
  "config": {
    "vendor-dir": "Packages/Libraries",
    "bin-dir": "bin"
  },
  "require": {
    "typo3/cms": "6.2.*",
    "typo3-ter/realurl": "*"
  },
  "replace": {
    "typo3/cms": "*"
  }
}

and get:

$> composer install
 [InvalidArgumentException]
  Unknown downloader type: t3x. Available types: git, svn, hg, perforce, zip, rar, tar, gzip, phar, file.

The patch works to some extends - although we loose portability but that's acceptable for our needs. However, the patch fails when it comes to update.

 [InvalidArgumentException]
  The symlink target "index.php" already exists.

I can remove the index.php, but next time I run the composer update the error is showing up again.

[PowerKiKi]

Same here, I would love to solve this issue, especially since the symlink thing is an officially recommended way to install TYPO3.

I noticed that the replace variant would not generate identical autoload files. So I'd bet something will break sooner or later. IMHO the approach suggested in this PR is the way to go.

[ghost]

What is the benefit of having the core symlinked in a composer setup?

[pniederlag]

The symlink thing is an official recomendation that was setup long time ago (read: before composer showed up on stage). Adding a symlink here is imho absolutly agains the principles of composer, or any other dependency manager. There are well established ways for dependency management, being it gem/bundler, npm, pip or composer, let's please stick with these principles and don't add "the TYPO3 way" because it's the way you have taken in the past. I had to say by-by to my well established /usr/local/typo3_src/XXX directory that has accompanied me since some time in 2001... guess what? I don't miss it! :)

How do you want to ensure the integrety of the code that is inside the symlink?

[tmaroschik]

Hey, I'm already started the next step of full composer integration for the core during the April Codesprint in Rosenheim. I came pretty far from a proof of concept point of view and have to continue on that.

Currently I'm heavily working for the T3DDs so I cannot continue on that. But I've got 2 weeks of holidays after the DDs to finish that work. By that time TYPO3 will be shaped in a more composer friendly way.

The pattern of working with a symlinked core will need to disappear completely in composer environments, because its actively breaking the "composer way".

I'm strongly against this change here because, it's simply not how composer works. Composer ties in your dependencies "per project" so using anything outside your project is breaking with this concept. So if you want to work the old way, you shouldn't use composer.

I'm open for discussion, but for now I close this pull request and reopen it once I'm convinced of that or overruled.

[PowerKiKi]

TYPO3 core is roughly 100MB. If you are hosting several sites, it can quickly become significant. 50 sites and we are talking 6GB wasting you precious, limited SSD storage.

Would your backup system be a bit too simplistic and that could have a huge impact on time and space used.

Using a symlink not only avoid those potential difficulties, it also make updating core across lots of sites easy as pie.

I am sure there are official arguments for this particular setup in TYPO3 documentation. Would be interesting to find them...

[tmaroschik]

@PowerKiKi This behavior will never be part of the cms composer plugin. The core won't imply any special directory structure soon anymore like now. So if you really need this behavior you can provide it via an own composer plugin, that can be required in your root composer.json then.

[PowerKiKi]

Sorry, I was offline when I wrote my reply and did not see your replies before mine was automatically sent.

I 999% agree with you that things of the past must be broken and be forgotten from time to time. And I am glad that you feel strongly in favor of composer. And since several people feels that the symlink thing should and will disappear in the near future, then I'll be more than glad to join you.

My original answer was only meant to preserve the "official" way. If that changes, then I'll be the first to follow a more modern way of working :)

We'll just have to slightly adapt our workflow...

[PowerKiKi]

I am actually surprised to find that master version of install instructions still mentions this symlink.

@tmaroschik would it be part of your planned work to modify that ? or should we go ahead and suggest a patch ourself ?

[tmaroschik]

@PowerKiKi Currently the plan goes in the direction of a composer mode, and a non-composer mode for CMS. So in non-composer mode the install instructions will be still valid, while in composer mode things will go the composer way. The install instructions will be changed once this all is implemented and considered stable.