Future of this extension

[michael-e]

I noticed that the S3 library used in this extension doesn't seem to be maintained well anymore. It has some open issues and rather few commits. In addition it doesn't work with AWS Signature Version 4, which is needed for any new regions after January 30, 2014. (For example, the new "Frankfurt" region.)

So I think about switching to the official AWS SDK for PHP. Of course, this is a big library… But probably this one will be maintained better. (And I verified that it's working with Signature Version 4.)

Any thoughts on this?

Should I rather build a separate/new extension?

Is there anybody who has time and interest to help with this (starting not now, but in the next few weeks)?

[nitriques]

IMHO, I think that using the official sdk is the way to go...

[michael-e]

@nitriques, in a different thread you mentioned that "every third party dependency should be behind a facade".

Ho would I do that? Create a special class which in turn uses the library? (Serious question, I really have no idea.)

Regarding the use of composer, should I see the extension as a project on its own (having its own composer.json file)?

[nitriques]

How would I do that? Create a special class which in turn uses the library?

Exactly. This "special class" can be a static facade or a singleton (please prefer static if possible (no internal state needed). That way, the code does not look to be tied up with the third party sdk and moving to another lib becomes trivial.

Regarding the use of composer, should I see the extension as a project on its own (having its own composer.json file

I am not an expert on that subject, but as @jensscherbl said (symphonycms/symphonycms#2194 (comment))

Composer installable packages should be usable in any context. You can't use a Symphony extension in a Laravel application for example, so extensions for a particular system should be handled separately.

So no, you do not need a composer.json file

[michael-e]

Thanks for the pointers, really appreciated!

But if I understand @jensscherbl's explanation correctly (and look at one of his own extensions), a composer.json file should be included in the extension.

[nitriques]

a composer.json file should be included in the extension.

I think that's only for managing dependencies with composer (CLI interface), not for sharing the extensions per-se. So the .json file is required if you want to play with composer, but not required Symphony-wise.

[michael-e]

Sure, Symphony doesn't need it. But if it is included in the repo, forks/contributors can also work with composer, e.g. update the vendor stuff to newer versions. Right?

[nitriques]

But if it is included in the repo, forks/contributors can also work with composer, e.g. update the vendor stuff to newer versions. Right?

I would think so, yes!

[michael-e]

Thanx, I will try my best!

[nitriques]

My pleasure!

[jensscherbl]

But if I understand @jensscherbl's explanation correctly (and look at one of his own extensions), a composer.json file should be included in the extension.

Only if an extension developer uses composer to manage third party dependencies for that extension.

But if it is included in the repo, forks/contributors can also work with composer, e.g. update the vendor stuff to newer versions. Right?

You could use composer to update dependencies on your own if necessary. But there's no guarantee that a project (in this case an extension) still works after updating dependencies to newer versions.

That's what the composer.lock file is for. It ensures that other developers get the exact same version of a dependency.

For example, the third party library I use for the CommonMark extension hasn't reached 1.0.0 yet and can break compatibility with every update.

Because there isn't a stable version I can rely on, I didn't specify a version number at all in my composer.json. Usually I would specify the major version and assume that the package respects semantic versioning and doesn't break compatibility until the next major version.

In both cases, updating and testing dependencies with my code is still my responsibility, and the composer.lock ensures that other people always get the latest version I used for development, even when installing via composer.

---

Further reading... Composer: It’s All About the Lock File

[nitriques]

Thanks Jens!

[michael-e]

Yep, thanks, @jensscherbl!