Synthetic labels for RIP, MIA, etc

[braver]

Fixes #234

Pushing what I have so far to get feedback. I just have the visuals and the markup, I didn't actually implement search/filtering (yet): clicking e.g. "unmaintained" will give no results. I intend to implement that once I remember how that stuff works 😅

• moved the RIP/unmaintained labels out of the top left
• they now join "st3" etc together with the labels and platforms in the bottom left (looks very clean IMO), in lower-case
• I changed "<st3" to "st2" because that's what pc.io does and it's easier to read (I think "st1" never had package control? it's very long ago) - let me know if that's a mistake
• I propose to not ride along on the labels:"foo" filtering because these are not actually labels. It's certainly easier to implement, but I think it muddies the data you're actually filtering on. Instead perhaps introduce state:"foo" as follows:
  • state:rip (removed)
  • state:unmaintained (archived_at)
  • state:st2 (outdated)
  • state:st3 (st3_only)

Example card:

Example detail page:

Another card:

Last one for good measure:

[kaste]

Haha, okay we have two camps here: the UPPERCASE and the lowercase.

• What I actually discussed with myself back then: they should appear last. So we have the special platform tags/buttons (colored), the grey user tags, and then the status tags (colored, stylized in someway). (You see already: status or state?) Doesn't have to be that way, just saying what I did and why.

• A simple objection: I don't think "unmaintained" is bad. I always thought this should be welcoming to mark the repos archived, and for others still to use it. That's like "info", "note".

• I would have changed "unmaintained" to "MIA" now. It is still just too long, and either you're cool and do "RIP" and "MIA" or explicit and do "archive" and "unmaintained". But you don't mix that. (In the mid terms I would add "Crawler had problems" as a tag too because that's interesting for us and not overwhelming because thecrawl seldomly has problems actually. (knock-knock) So that tag would be a yellow "50x" if we're cool and something explicit if we're not. Just something to have in mind.)

You don't get me if you don't show the meat, the easy way to search. I think a generic "tags" (aka labels) idea (in a backend) must hold here and just support that. Can there be clash with user tags? Yes of course, but unlikely in a meaningful way. (Tags must pass our review.) You can also do special, reserved tags like ":st3", and still style/present them as "ST3" of course because that's part of the ever-growing presentation layer. (I would maybe ditch the platforms as well, if we can: e.g. Linux and Mac are present, hence tag the package as "not-windows!".) I would have added them to the labels page too.

But maybe just tell what you imagine why the backend needs a feature split here.

[michaelblyons]

• FWIW, I think r.i.p. looks strange. I think moving to archived or removed is better than changing unmaintained to MIA. (Though archived as a tag name kind of conflicts with the fact that unmaintained means the GitHub repo is archived.)

• I like the ideas both to add to the labels page and to add the crawler failures as a distinct option.

  • Minor point: If crawler failures are added, I hope that we can use the same verb form as the other states, like crawl-failed.

• Styles in OP are fine with me. Other styles might also be fine.

• No opinion on removing the platform labels from the front page.

  • I have occasionally thought that using the same style for all the platforms might be okay, especially if Some labels should stand out... #82 goes forward.

You don't get me if you don't show the meat, the easy way to search.

Fair. I do it's worth considering the UX too, even if the functionality hasn't been written.

the backend needs a feature split here.

This part I'm not sure I understand. Do you mean label:X vs state:X/platform:X/label:X?

[braver]

the UPPERCASE and the lowercase

I'm not in either camp per se. RIP, MIA in uppercase also works for me. Those should definitely be in caps.

they should appear last

Again no strong opinions from me here. It is not necessarily the most important thing about a package, so yeah, let's put them last.

I don't think "unmaintained" is bad.

Had the same thought. It was red before and I kept it. But although it is kind of a bad sign, it doesn't mean the package won't work. So, yeah, orange there instead of red.

changed "unmaintained" to "MIA" now.

Well the author is missing in action right, not the package itself? So I would lean non-cool "removed", "archived", but that's just cause I'm not that cool 😎 RIP/MIA also works for me, and is nice and short.

But maybe just tell what you imagine why the backend needs a feature split here.

Well, perhaps I'm bringing too much knowledge of the package registry into this. But I expect that all labels I see on the site, are also labels I would see in the registry (ie. in the json's). As an author, I submit a package with labels of my choosing on them. It's unexpected that the system adds labels of its own. Labels are a specific thing, and these are perhaps kind of labels, but synthetic....

... but this is also why I wanted to present the PR before I implement anything: I'm not sure on my position there. I think I might have over-thought that a bit. I guess it's fine if they're labels, but they're just "synthetic", or generated labels. It makes using it easier (everything that looks like a label is a label) and it's also easier to implement. So, I guess I changed my mind on that now 🙂

No opinion on removing the platform labels from the front page.

Honestly, the only reason they're there at all is to add a little color. I think visually it needs something like that, it's a sea of grey otherwise. Even though they're essentially useless. But that's not what this PR is about and I'd like to leave that discussion out of scope.

[braver]

• moved to the end of the labels
• uppercase
• use "labels" in the "backend" - which also concludes implementation because that already worked 😄

Making this PR mostly aesthetic 🧑‍🎨 Unless I really missed something, ready to ship?

[kaste]

It's not only aesthetic if we now can search for RIP and MIA packages which is a big to-have actually. (also if we at some point can find crawl failures in such a way.)

I don't dig the style. I do like if it gets finer and thinner (compared to the current one). It is I think just the grey background. It just hinders the contrast -- I don't know. On the card, I would do e.g.

The transparent background normally, and the colored background on hover. (My mouse isn't in the screen capture. 🙄 )

Compared to yours

Generally, as long as we have them distinguishable from the "normal" user labels, it is also clear that they come from elsewhere. (I think we can easily also imagine a "top-pick" label here and make it visually clear that this is a special label the package owner didn't awarded himself.)

I commented otherwise in the code.

Btw "doa" isn't a thing anymore as I "backported" first_seen for all packages. (Doesn't need to be part of this PR of course.)

[braver]

On the card, I would do e.g.

Love that, looks good 👍🏻

Btw "doa" isn't a thing anymore as I "backported" first_seen for all packages

Oh, that's certainly good to know. If I can drop DOA that simplifies this PR a bit as well.

[braver]

[kaste]

💪 ⛵ it

[braver]

🤞🏻

[michaelblyons]

I checked out the ST3 label search which amusingly has one package literally tagged st3 and only two packages whose compatibility versions designate them as ST3 only.

I also checked out the ST2 label search and I'm a little concerned that it might be communicating something incorrect. Those packages may not have specific tag series since ... ever, but that doesn't necessarily mean they don't work for existing ST versions.

[kaste]

They have a very specific tag series, these are marked "<3000". Unless I made an error or we're confused.

[michaelblyons]

They have a very specific tag series, these are marked "<3000". Unless I made an error or we're confused.

Wow, you are right! There are many of those! Much more than I imagined.

See also: sublimehq/package_control_channel#9100 and sublimehq/package_control_channel#9105