Adding libraries page and data simplification

[TerminalFi]

TerminalFi.2025-06-29.at.14.19.44.mp4

[braver]

To avoid conflicts, let's try to do this without affecting the CSS too much (at least base stuff like colors).

[braver]

Can we reuse the cards so that we don't introduce too much new code (layout, scripts) to handle this list? It looks like the content would fit in the 3-column card layout.
Edit: also considering the fact we probably want to have a list (vs grid) layout for packages as well. Ideally the detail page can be abstracted in a way that it can handle content for both. At least without introducing new CSS.

[braver]

If it helps, I could also live without sorting options on the library page. There are fewer useful options here, and likely you're never comparing multiple alternatives for the same feature: you just need to be able to find the specific one you're looking for.

[kaste]

Don't know where this fits but seeing the results lists here feels more useful and superior. Typically, the landing page could have cards, even visually very dense (i.e. with less information) cards, but as soon as I search -- I think -- scanning a list is optimal. It is just eyes on the left, then top -> down. That one doesn't fit at all here: Sort by last updated (most recent) and last added are useful. Sort by stars reversed typically not so. :sorry:

[braver]

but as soon as I search -- I think -- scanning a list is optimal. It is just eyes on the left, then top -> down

Yeah, that’s a great way to do it: cards on the homepage, list when you search. 👍🏻

[MarketHubb]

When viewing items in a vertical list, independently encapsulated cards with a vertical gap is (probably) too much structure.

I would suggest that, when in a list view, applying background contrast the container and bifurcating the individual packages with a simple border-bottom.

We're already using a grid layout on the parent <ul>, so as long as there's some targetable class on the body or list container denoting the layout type (grid or list) you could easily modify the existing card layout to become a list layout with a descendent selector (almost no modification to the card structure or existing css).

I took the existing layout in my PR from last night, and simply wrapped the package title and author in a flex container so they could output in the same row on list.

Example

[braver]

Love how that looks! 👍🏻

[FichteFoll]

Just for the record and to provide some context to this PR, PC5 may or may not have a fallback to the entirety of pypi, which would make a separate library listing redundant. (via sublimehq/package_control#1705 (comment))

However, PC 5 is still far and away, so don't let this stop you from adding a libraries page.

[deathaxe]

Various libraries, which may be used by PC5 already move on dropping support for python 3.8

Hence it is not yet for sure for PC5 to support already EOL'd python 3.8 or just will make a cut and start fresh on python 3.13 only.

In later case, PC4 will be the one to drive all ST builds from 3143 to 4200 and so the whole ecosystem must be prepared to. Don't expect huge functional changes to PC4 as it claims support for ST3 and python 3.3.

[braver]

@TerminalFi given that the dataset is indeed just 119 records, with no metadata or detail pages, and the target audience is much more niche... Let's just add a single static page with libraries. That way we can build that listing bespoke for this purpose without introducing factories and abstractions, and without pulling all the complexities into this space as well. A simple keyword search can be added if someone feels like implementing that (honestly for this use case I think CTRL+F also works), but we don't have to mess with sorting too much (most of the metadata to sort on isn't here anyway).

Given that brief, do you still feel like implementing it and do you have time for that, or shall I give it a go?

@deathaxe @FichteFoll am I correct in understanding that this would replace http://packagecontrol.github.io, and that that's built on effectively the same data?

[deathaxe]

Old page just pulls static list of libraries and shildio badges to provide current versions, client-side. Given its source is the old channel, it is more or less out-dated anyway. With a libraries page added to packages.sublimetext.io, I'd vote to retire the old page.

For the new page however, we should probably use workspace.json to also display resolved versions. There may be different ones for python 3.3 and 3.8 and maybe 3.13 later on.

[braver]

we should probably use workspace.json to also display resolved versions

That makes sense. The workspace file currently doesn't have libraries (the dependencies array is empty). We can also just do what the old page does for now and improve on it later.

[deathaxe]

Sure. Just hope we can replace separate libraries channel crawler at some point as well, so a single crawler handles everything.

[braver]

A relatively simple page was added in #55. I think we're good for now, we can iterate (if needed) in smaller steps. And indeed, the main work would be in resolving the crawler situation. All in good time :)