Project

General

Profile

Actions

Bug #54142

closed

Dependencies for non-composerbased extensions not regarded for ordering PackageStates

Added by Stefan Froemken over 10 years ago. Updated over 6 years ago.

Status:
Closed
Priority:
Should have
Category:
-
Target version:
Start date:
2013-12-02
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hello Core-Team,

I have installed direct_mail and tt_address, but tt_address was loaded AFTER direct_mail. I have added tt_address to ext_emconf.php in direct_mail with and without versionnumbers. And I have deleted PackageStates.php and let it rebuild. But tt_address will not be loaded before direct_mail!!!

I have debugged the PackageManager and found following lines:

if ($this->packageRequirementIsComposerPackage($requirement) === FALSE) {
    // Skip non-package requirements
    continue;
}

As you can see: non-composer/packaged-based extensions will not be added to the list of dependencies for a given extension (direct_mail)

Any idea why you don't like "normal" extensions in this list?

Stefan


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Bug #54581: Please repair PackageStates before next Beta!ClosedThomas Maroschik2013-12-23

Actions
Actions #1

Updated by Thomas Maroschik over 10 years ago

  • Category deleted (Install Tool)
  • Status changed from New to Accepted
  • Assignee set to Thomas Maroschik
  • Target version changed from 6.2.0 to next-patchlevel
  • PHP Version deleted (5.4)
Actions #2

Updated by Steffen Ritter over 10 years ago

  • Target version changed from next-patchlevel to 6.2.0
Actions #3

Updated by Gerrit Code Review about 10 years ago

  • Status changed from Accepted to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26619

Actions #4

Updated by Kasper Ligaard about 10 years ago

This issue is the reason we have stopped all TYPO3 6.2 plans: Testing our setup with TYPO3 6.2 means installing and uninstalling extensions; this issue makes that impractical since we constantly have to battle with the Extension Manager.

As I have understood the new Extension Manager, then installation of Composer packages is an new capability; "Old style" TYPO3 extensions it should work exactly as before. (please correct me if I am wrong). Assuming I am correct I see only two ways forward:

- Make it work before completely 6.2beta3. Which would likely mean somebody working full time from now on.
- Revert the Extension Manager to the way it worked in 6.2alpha3. Composer packages could then be included in the Extension Manager in 6.2.x.

Even if somebody can work full time on the Extension Manager from now on, I seriously doubt that they will be able to fix all the corner cases before beta3. Having an Extension Manager that works 99% of the time just isn't good enough.

Shipping an Extension Manager that "mostly works" in TYPO3 6.2 will tarnish the image of the whole release, since we can assume that people will be installing and uninstalling extensions when they have just upgraded. Postponing TYPO3 6.2 yet again just because the Extension Manager is not ready with the Composer capability wouldn't make sense either, since we can add that feature in af 6.2.x release.

Thus I my view the Extension Manager with Composer support should be postponed to whenever it has been finished and proven ready.

Actions #5

Updated by Stefan Froemken about 10 years ago

Hello Kasper,

I'm not part of the TYPO3-Core-Team, so this is only my personell meaning:

The Coreteam will meet at the end of january here in cologne for a Codesprint: http://wiki.typo3.org/CMS_CodeSprint_2014/1:_K%C3%B6ln
I will be there and I hope that we can discuss this ticket here, too. Another opinion I heard was "If we don't get it stabil, we revert this feature"

Stefan

Actions #6

Updated by Thomas Maroschik about 10 years ago

Hello Kasper, hello Stefan,

thank you for your comment. This bugfix solves exactly what it describes. It fixes the dependency handling in the Package Management API. This is the underlying lowlevel logic for the package/extension management. Support for composer packages is rather a sideeffect of the Flow API backport. The ExtensionManager is rather unrelated to this bugfix as it's the Extension Management GUI on top of the Package Management API.

The dependency handling of the Package Management API works now after this fix.

What still does not work (and I just proved it not working in 6.1 too) is:
If extension A depends on B, and B depedends on C, then C does not get installed. I tracked it down to a conceptual Extension Manager issue that needs some rewriting of the EM code. But this is a different issue.

Greetz,

Tom

Actions #7

Updated by Gerrit Code Review about 10 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/26619

Actions #8

Updated by Kasper Ligaard about 10 years ago

Whatever systems (or subsystems) might be at fault, the bottom line is that if TYPO3 6.2.0 is released with the current Extension Manager, then people upgrading or new to TYPO3 will have a bad experience. That this fault has gone unnoticed also in 6.1, indicates that not many people are using the 6.x series, which probably shows how wary people are to upgrade to a system that has a reputation of being unstable (factual or not). We need TYPO3 6.2.0 to "work as advertised" for the end user, lest we risk that TYPO 6.2 will be percieved as faulty. When it comes to the Extension Manager we can use the EM from TYPO3 4.7, in case the problems in the current EM cannot be fixed very soon (if that means postponing Flow package support to TYPO3 6.2.0+, then so be it).

Some of the problems we seem to have with the Extension Manager in TYPO3 6.2.0beta3 are the following:
  • No dependency resolution. No such thing as an partial dependency resolution exists: Either it is done completely or it is not dependency resolution.
  • When installing an extension that requires some other extensions, then the are all installed (except of course those that are dependencies of the dependencies) but no indication is given to the user that more than one extension was installed.
  • When dependencies are installed they might need some extension manager configuration. The Extension Manager does not prompt the user at those points to ask the user to configure the extension; some extensions can crash TYPO3 if not configured (we can agree that those extensions are poorly written, but that still provides a poor user experience for the end user).
  • Uninstalling an extension which depends on some other extension also uninstalls that other extension - even if some already installed extension also depends on that other extension...
  • ...and the uninstallation is done silently, so unless the administrator knows which dependencies the installed extensions have, then he's in for a unpleasant surprise! (and not needing to know the dependencies of you installed extensions is what the Extension Manager is supposed to handle).
  • The EM also uninstalls extension that are not even in the dependency chain - at least I cannot explain why EXT:devlog should be uninstalled?!?

PS: I was not aware it was the Flow package backport that has caused these problems (I thought Composer support was a separate feature). In light of that information it is the Flow package backport that I propose be postponed to whenever it has been proven ready.

Actions #9

Updated by Ernesto Baschny about 10 years ago

  • Subject changed from Dependencies for non-composerbased extensions were not collected to Dependencies for non-composerbased extensions not regarded for ordering PackageStates
Actions #10

Updated by Ernesto Baschny about 10 years ago

Kasper, thanks for your points and observations. Those are mostly valid and very important to solve before 6.2 release, but they are unrelated to this issue in specific. I changed the subject so it's clear what this is about.

Please open new issues for your findings, or search the tracker if those haven't been reported before.

The plan is to collect the most important UX and bugs of the EM before our Code Sprint in Köln (end of January) so that we can tackle them individually. I appreciate your help on doing that triage! Thanks!

Actions #11

Updated by Thomas Maroschik about 10 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #12

Updated by Kasper Ligaard about 10 years ago

@Ernesto: I feel like you are shooting the messenger. Anyways: It is correct that is issue not the place for this discussion.

Actions #13

Updated by Riccardo De Contardi over 6 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF