Bump to latest Symfony

[tacman]

Hi, Symfony is now at 7.1, what are your thoughts on updating this to the latest version of Symfony and PHP?

[samwilson]

I was actually just looking at doing that this morning on the bus! I'll see what I can do. :) This project hasn't had much attention recently. :(

[tacman]

I was thinking about creating a Symfony 6.4+ bundle for this. The CLI could easily go there.

The main reason I want the bundle is to be able to put the API key and secret in environment variables, and inject the service with the keys already set.

Then we can also add things like a cache expiration time.

It's MUCH easier to create a bundle in Symfony 6.4.

[samwilson]

Would the idea with a bundle be that it'd be easier to integrate into other applications? Wouldn't that mean we should have two repos, one for the bundle and one as the actual application (i.e. this repo)?

I'm happy to to whatever's most useful!

Regardless, I think adding support for setting API details as env vars is a great idea (and could happen with or without a bundle, I think). I also want to move the default location of the config file to $XDG_CONFIG_HOME/phpflickr-cli.

Anyway, as far as upgrading goes, I think it's time to drop PHP 7 as well. :)

[tacman]

If you want, I can create the initial bundle and register the command then transfer the repo back to you.

So there would be 3 repos: the library, the bundle, and a demo repo that shows off the integration.

Then the developer can run the auth command, get the credentials, and integrate it into the application.

[tacman]

Now that I see what the CLI does, it probably doesn't make sense to be in the bundle, as it really is a stand-alone application.

But instead of being CLI only, it could really be a Symfony app that also includes a CLI and basic UI.

FWIW, here's my use-case: https://www.flickr.com/help/forum/en-us/72157722820227503/

[tacman]

Some brainstorming. I see that the metadata is dumped as .yml files along side the jpg. My first thought: "Why not json?".

But the bigger idea is that the developer wants to iterate through the data and do something. Which of course they could do by calling the API directly. But if the CLI were in a Symfony bundle, the developer could registered listeners and the CLI could emit events.

Again, I'm just brainstorming here.

bin/console make:listener 
bin/console flickr:download:album --album=72177720317358478 

final class MyFlickrMetaListener
{
    #[AsEventListener(event: FlickrMetaEvent::class)]
    public function onFlickrMetaEvent($event): void
    {
        $data = $event->getMetadata();
        // save as .json, to a database, sync, dispatch a download request, whatever
    }
}

[samwilson]

Now that I see what the CLI does, it probably doesn't make sense to be in the bundle, as it really is a stand-alone application.

Yep, it's designed to just be a simple CLI and not really anything else. The common Flickr API parts are in https://github.com/samwilson/phpflickr, although I guess what you're getting at is that things like serialization and event hooks and those don't really belong in that general API package either.

Dumping metadata as YAML was just the first way; adding JSON totally makes sense. I've opened #23 to track this.

I've created #21 to upgrade the dependencies. I notice you started this also, in #22, sorry that I didn't update this thread earlier with my progress!

[samwilson]

All dependencies are up to date now I think, so this can be closed.

[tacman]

"config": {
        "platform": {
            "php": "8.0"
        },

8.0 is EOL.

What's the benefit of doing this rather than putting

"php": "^8.1",

in the require section?