-
-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Moving to Github Pages, Python 3, general code and dataset review #448
Comments
Python 3 fixes and a Pages workflow are on the default branch here: https://github.com/ali1234/Pinout.xyz That repository is auto syncing to https://pinout.zerostem.io on every push (currently English HTML only.) |
I need to get around to looking at this. I'm really keen to move over to GitHub pages to make keeping the site up-to-date easier, and potentially helping me delegate more responsibility to community members who've helped over the years. Should they want it! An org actually sounds like a great idea. I had forgotten this issue exists (it landed just about the time we we're at critical with baby preparations) and was just wondering how to handle multiple subdomains for languages. It seems an org, and just repos that do nothing but contain the generated HTML files would be a reasonable approach. |
Oh and I think a lot of the friction with the Pi database is - reading between the lines here - just how awful this code and dataset is. It grew very organically and I tend to get caught up trying to optimise the actual end result rather than the process to produce it. Maybe a better system will make Pico and MicroBit board databases, and alternate pin layouts (for third party boards in RP2040s case) more attainable. Have had an org set up for a while, must have forgotten about it - https://github.com/pinout-xyz |
Abstract:
On moving to Pages:
make
, and upload from the output subdirectory instead of the repository root.Code review and Python 3 changes:
map()
is passed directly to the JSON serializer. This no longer works in Python 3 becausemap()
returns a generator object. The easiest fix is to wrap the calls inlist()
.slugify()
andcssify()
- even the ones that don't use them. Additionallyload_md()
appears a few times but is never used at all.pillow
is missing from requirements.txt. It only seems to be needed for generating the API.On the dataset itself:
bcm
in their number, they should all be converted to strings.Some errors can be seen in the above. For example, somewhere there is a pin which has a mode without a number. Note that not every path appears in every file, which makes parsing a bit harder. The list of paths that are always present is surprisingly short:
So that's the state of things now. Fixing all these problems is a design challenge. Normalizing the data for a new design should be very easy to automate. Another consideration is the microbit and pico sites. If we are going to completely redesign one of them we should probably make it general enough to drive all of them, and anything new that comes out in the future.
The text was updated successfully, but these errors were encountered: