Sorry, but this has been rejected before in #2378.

First, thank you for reviewing this pull request.

But I strongly disagree with the reasons given in #2381.

1. I have "flooded the planets" before. It was embarrassing and, as a result, I started applying uuid4 guids to all my posts (in the ikiwiki iteration of this site). It hasn't been an issue since.

2. As such, I have seen readers use GUID to track read status; and iTunes (which is the consumer I'm currently targeting) explicitly states that GUID must not change.

3. I'm not trying to support moving domains; but, as-is, I can't move posts at all without making them re-appear in a reader. That's incorrect and embarrassing.

4. I don't see how an optional parameter complicates Nikola's user interface over practicality. As-is, this cannot be done in a plugin without duplicating the RSS renderer. Show me how to do it in a plugin, and I'll move the code there.

I'm totally ok with leaving the derived permalink as the default; but since it's not actually a permalink (it changes if the post moves) it should be possible to specify something actually permanent if I want.

@da2x, @ralsina: opinions welcome.

How about instead having the possibility to customize RSS/Atom feed generation? Like having a signal which passes the XML object, so that signal handler plugins can hook up to the signal and add stuff? That would allow to add such specific things without modifying Nikola core.

Depends a bit what the signal call passes as its arguments. Passing the XML object and the post list would be a good idea. (You can of course find the posts based on the generated XML, like by using the guid, but that's kind of hacky.)

(There's also a different solution which doesn't require any support in Nikola core: you could monkey-patch the Nikola object by replacing its generic_rss_renderer method by your own function, which does whatever you want. I wouldn't recommend doing that, though.)

I fully agree. I think it makes sense to provide the signal handler with a list of pairs (post, extended_item) next to the rss_obj (and next to site). That should allow to make modifications very simple.

Regarding iTunes tags: that would only partially work, since you don't know in the signal handler whether this is a feed where itunes == True is passed or not. Also, you'd have to monkey-patch ExtendedItem to actually generate the needed XML.

(Signal handlers are well suited for changes which affect ALL feeds, not for specific ones.)

Sigh. It's a valid issue. I suppose if the post has a guid metadata it could be used, defaulting to what is used now. If it breaks something else when used, you get to keep both pieces :-P

The RSS/Atom generation is unwieldly, and it could be improved, but backwards compatibility is a must. If we change things the wrong way we'll make everyone flood the planets.

While the discussion is happening, can I get the "duplicate" and "wontfix" labels removed from the PR? I'm happy to continue discussing the best way to do this, and learning about signal handlers is probably good; but those labels are vexing me. :)

fwiw, I liked the idea of a signal handler that would receive (post, extended_item) pairs. Can extended_items be edited in-place? I've only used them to append.

I removed the labels. For your other question: I guess so, but I don't really know. I've never worked with the RSS feed code.

So what's the current thinking? Does this need to become "enhance RSS feed generation to support signal handlers" or is the existing implementation path acceptable?

The last time someone suggested this feature, it was opposed by the argument that most feed readers ignore the GUID anyway. Since we now have one very specific example where the ability to specify a GUID is crucial (iTunes podcasts), and this fix is very simple and doesn't add much complexity, I suggest the original concerns do not apply anymore. @ralsina, @da2x, @tritium21 (you three opposed the previous PR): do you agree to that? Or do you still have concerns against this?

I’m for merging this as-is.

Already merged, but because of the implementation of this version of the feature doesn't break history like the old one did, I have no objection to it.

(I think the old implementation of this feature also didn't break anything. It added a function to Post to retrieve the GUID and also inserted it into Atom feeds, but its default fallback when the GUID wasn't explicitly specified was also to use the absolute permalink as before.)

I looked at the old implementation....at least the version of it I saw simply swapped the guid from the permalink to a metadata field. That broke stuff. I didn't check, just now, if that was changed in later versions, and I don't remember offhand.

With a use case, and a non-breaking simple change, I cant see a problem

I just looked in the commit referenced in the old PR: julianbrost@40ba642 That one only uses the GUID from metadata if it is specified there, and otherwise uses post.permalink(lang, absolute=True).

Fwiw, the implementation in #2378 looks better than mine / this PR to me.