Make spyder.rb user python 3.4

[vitorgalvao]

Refs #8127

A change in the app bundle’s name implies a change in the token. 2 is included since it refers to the version of python, not the softeware itself.

[tapeinosyne]

Apologies, I should have waited for feedback before merging. Elision of py2, which stands for “Python 2”, would be supported by our conventions on framework substrings.

Of course, this is only applicable in the absence of a casked Spyder-Py3 package.

---

According to the Spyder download page, the Python 3–based package not only exists, but is also more popular.

With the intention of offering both packages, what is our best course of action?

We would normally be inclined to move the less popular package to Versions. However, considering that both Python2 and Python3 are available through the main repository, we may want to be include both here.

(Addendum: switching a payload without renaming the Cask is undesirable, and will be even more problematic once we implement our upgrade verb.)

[vitorgalvao]

Apologies, I should have waited for feedback before merging

No worries. I left this purposefully unmerged for discussion on its desirability.

However, considering that both Python2 and Python3 are available through the main repository, we may want to be include both here.

Agreed.

switching a payload without renaming the Cask is undesirable, and will be even more problematic once we implement our upgrade verb

Isn’t the goal of storing metadata to mitigate those?

[rolandwalker]

As to this Cask, I reckon that the -py2 suffix is a toolkit and thus should be ignored. And I see another example psychopy.rb.

As to the larger point, we have done a fair job reducing the conflicting constraints on the token. However, there are two that remain: following the app bundle is good, because it gives at least some protection against collisions, and is straightforward to derive. But rename events are bad, because even after storing metadata, we don't track renames at all. So upgrade won't know how to proceed if caught in between a rename. (However, uninstall is about to start working better.)

There are a few different ways to improve this situation, such as declaring a freeze on all existing tokens, or starting to track renames with a renamed_from stanza or separate data store. I believe Homebrew uses a separate data store.

[ccordoba12]

Hi guys, Spyder maintainer here. I released our dmgs for Python 2 and 3 with different names, so that your users can install them side by side without problems.

I didn't know about your project until last week but it seems pretty cool, so I'd like to support it better. Please let me know if you need anything else from us.

[vitorgalvao]

Thank your for the offer, @ccordoba12.

@rolandwalker I certainly see your point. However, how do we add spyder-py3 at all, without renaming this one to spyder-py2? We keep one as spyder, and to the other add -py<number>? Isn’t that a worse solution than adding it to both?

I also had the idea tracking renames was one of the features of storing metadata (even if not yet implemented). Was that idea dropped, or was it never there, and I just though it was?

[rolandwalker]

Hi @ccordoba12 ! Welcome!

@vitorgalvao I have no strong opinion here; I was just trying to look at past practices and seek consistency.

It looks like the way we handled most variants so far was to put one under the defined/default token in the main repo, and the other under a more freeform token in homebrew-versions. Like openoffice.rb in the main repo and variant openoffice-fr.rb in versions.

There are some other cases where both variants live in the main repo such as intellij-idea.rb / intellij-idea-ce.rb, though I have no idea why that is.

I never got too worried about oddball tokens in the versions repo because hopefully we will inline all that info into the primary Casks later using a variants block. And we have already been successful at removing things from the versions repo just by figuring out the rules to make if blocks sufficiently performant.

As to tracking renames: no we don't have that feature, but I probably gave an impression there was an implementation just because I have raised the point often whenever we talked about upgrade/metadata.

In fact there is no way to track renames currently, which was why stable tokens were a prerequisite for the upgrade verb.

We could add a way to track rename events, but nobody has worked on it.

[ccordoba12]

I'd just want to let you know that we depend on our app name internally to check for several things, so if you rename Spyder.app to Spyder-Py3.app then several things will stop to work.

[vitorgalvao]

@ccordoba12 No worries there; our discussion is only about the app’s token: meaning the name you type when telling homebrew-cask to interact with it, it’ll have no effect on the app bundle’s name.

There are some other cases where both variants live in the main repo such as intellij-idea.rb / intellij-idea-ce.rb, though I have no idea why that is.

Because they’re not different (numeric) versions of the same app, but different apps (editions) altogether, I’d wager; same reason there are a ton of Eclipse variants present. We can likely find examples that contradict such a “rule”, though, and I’d also like to see them all consolidated. For such cases, though, choosing a variant would have to be mandatory, since no single one could be assumed as the default (and I have no problem with that notion).

As you, @rolandwalker, I have no strong opinion on this. It was actually due to forgetting that the rule to remove framework substrings exists that I submitted the change. It was due to @ndr-qef’s pertinent comment on the py3 version that the discussion took form. Since py3 is the most popular version, and to keep consistency with past practices, I propose we add it here as spyder, and move this current cask to caskroom/versions as spyder-py2.

If you all agree with this solution, I’ll proceed to make the change. Else, we shall find a different one.

[rolandwalker]

Agreeable here. I also noticed a similar case charles-openjdk.rb.

[vitorgalvao]

Done in Homebrew/homebrew-cask-versions@a1ec501 and this very issue (updated).