Making TER a proxy for git tags (or Packagist)

Comments TYPO3.org News
1

Mon. 29th October, 2018

What is your idea about?

This is a companion discussion topic for the original entry at https://typo3.org/article/making-ter-a-proxy-for-git-tags-or-packagist/
2

Why not drop the TER completely? Actually the TER could be a simple static website that only shows the filtered results of the packagist API. In addition I could imagine that it could be beneficial to

  • work together with packagist.com to ensure used packages are not unpublished
  • work together with coders.care / marketplace so an extension can be replaced with a maintained one without changing the composer.json

Of course that means that the Extension Manager in the TYPO3-Backend also needs to change. Maybe it is possible to completely use composer under the hood? Then no TYPO3-specific solution is needed anymore. A those kind of infrastructure could be also shared with other open source or commercial products.

A first step of course could be to automatically transform Git-Repositories to legacy extension archives, as described in the budget idea. But I think that it needs more than 5,000€ to accomplish this goal.

3

You can read about what contao did: https://medium.com/@yanick.witschi/composer-cloud-resolver-e64254f5728e this is something we can think of

4

The TER will get less important in future. But still it is an important component in our ecosystem and we will develop more and more in the direction of an easy to use catalogue for extensions.

If you are interested, you can discuss this with @tomalo.stuttgart

Stefan Busemann
typo3.org product owner

5

There are several reasons for not removing TER in the next - let’s say - months:

  1. Not all extensions are in packagist
  2. Many instances don’t use composer yet
  3. Many extensions don’t use composer yet (some extension don’t even use an open versioning system)
  4. Packagist has no possibility to mark unsecure extension versions, see https://github.com/composer/packagist/issues/335

That are some of the reasons that I just think about, but there are definitely more.

Yes, we are planning to rebuild the TER to create a beautified packagist image with some more meta data than packagist currently has. But that’s a process for over a year and should be well communicated what people has to do for the switch.

6

I do not get why it is so clear that we are talking about how to fund the server team to deprecate TER. We are trying to reduce infrastructure not replacing one part with a new one.

This idea, which I fully support btw., is about removing the need for TER entirely. In the long run one can therefore expect that funds that previously went to the server team become unallocated again.

In the meantime I’d suggest that TER will not be enabled to host extensions for TYPO3 10, rendering 9 LTS the last release TER would provide extensions anymore. We are already in the situation that 9 only provides subtree-split sysexts via Composer (which is good) but still a full ZIP package. IMO that does not make any sense.

I agree with @tomalo.stuttgart that many installations do not use composer yet. Therefore, please invest said money into beating the big drum for Composer-based deployments. Or even better: fund the entire removal of the code base handling legacy extension management out of TYPO3.
Of course, this is not about talking down your work on TER, but - seriously - its days are IMHO over.

7

In general I agree with you, but I have some issues with:

  1. The Server Team is spending money in infrastructure. The TER is one of 25 servers (https://status.typo3.org), so you won’t get that much money to invest in big drums
  2. Beating big drum for composer is good but most of the TYPO3 domains are hosted on hosting partners not providing composer or the possibility to use it via CLI. Therefore a UI in the TYPO3 Backend for composer should be mandatory.
  3. Why generally shutting down TER, why not showing just all composer packages with type “typo3-cms-extension”. Every CMS has an overview of packages, this is the first place a person is looking for.
8

Just one feedback about this point: There’s roave/security-advisories - Packagist and I think it makes sense to copy that idea for TYPO3 extensions.

2 Likes
9

Since I’m the leader of the server team, I’d like to point out that this project is a nice idea by Thomas and was not initiated by us. I also don’t see a necessity that only the server team can do that.

We will certainly host whatever will be the result of this project, but I don’t insist that anyone of the server team will implement it. @tomalo.stuttgart do you agree?

10

I’d like to point out that this project is a nice idea by Thomas

Well, that’s not only a nice idea by me. TER was there before my contribution and it’s a mandatory part of the TYPO3 ecosystem. :slight_smile:

11

I’ll start a “Future of TER initiative” at the begin of 2019 to collect all ideas and discuss how to get further and future-proof. Everybody is welcome to join.