{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiges3srikpwelhobmuht7hj7a7ngosbmvavkw3sjxsz43x5o6443e",
    "uri": "at://did:plc:hqad6xwuzg7oqfmwylfkvqfm/app.bsky.feed.post/3mhvr3sp6qgi2"
  },
  "path": "/viewtopic.php?t=33205&p=271428#p271428",
  "publishedAt": "2026-03-25T17:43:19.000Z",
  "site": "http://forum.palemoon.org",
  "tags": [
    "https://repo.palemoon.org/athenian200/U ... hon3-clean"
  ],
  "textContent": "https://repo.palemoon.org/athenian200/U ... hon3-clean\n\nSo... now it's cleaned up a bit. Obviously the branch is very out of date given how much time was spent, so it still couldn't be applied as-is, but thanks to the cleaner commit history, it should be easier to rebase this on master and clean up any conflicts as they arise.\n\nSo, this actually addresses most of the problems with the original port...\n\nfreebl3priv.so now seems to have the right name on Linux. application.ini.h is now found properly, and the dist/bin symlinks appear to work on Linux again. And I found a way to get it to use either kernel or OS enums for OS_ARCH and OS_TARGET (like we currently do) rather than restricting us to one list or the other for mozbuild files. I was also able to actually fix mozprocess rather than just stubbing it out.\n\nThe one thing I couldn't actually save in the end was virtualenv 15.x. I got it to work on Python up to 3.10 just to have it as a reference comparison against venv to make sure there weren't behavior differences (was paranoid after the dist/bin symlinks stopped working on Linux with my first build). There were none... apparently this build system is not dependent on virtualenv 15.x quirks at all... it would even run under system Python if you copied all the .pth files it generates into your system Python's site-packages and made them into absolute paths. virtualenv was apparently only ever a convenient way to make sure that developers didn't have their system Python polluted by references to mach, and that mach didn't accidentally find versions of packages on a developer's system that weren't what was shipped with the browser.\n\nBut yeah, this should work almost exactly like our current build system with minimal behavior changes, other than mozbuild being way more sensitive to incorrect enums and blowing up really early on in the build rather than when it hits the offending mozbuild file.\n\nThere is one BIG issue I just thought of as I was finishing this work, though... if a developer needs to go back in time through git history to before we did the Python 3 switch... they would still need Python 2.x in order to build the system at that point. I've been thinking about whether this needs to be addressed... and I came up with two basic ideas...\n\nThe first is that, after we've made sure this new version of our build system is stable (I honestly think it should probably be tested for months before we even think about making it the standard), it touched every Python file in our tree), we might have to go back in our git history to the very first commit and swap out the build system there, and then replay every later commit on top of that new version. That would probably be better to do on a new repo (or at least a new branch), effectively archiving the Python 2 one as a backup just in case we need to see the real history again.\n\nThe second potential idea I had, is that alongside something like that, it might make sense to gather up all the scattered Python scripts across our tree and unify them into a location like build or python, adapting them to work there, so that we can split platform/build and platform/python into submodules, and thus people would be able to move the build system and its Python stuff forward or backwards in time independently of the actual C/C++/JavaScript source code we usually work on. This might sound like overengineering, but I really think this could be a good application for the git submodule idea we're already using for the application directory. It would also mean if someone does want to build the Python 2 version of the build system, they could do that.\n\nNone of that really has to be done right away, though... and really the biggest obstacle to a Python 3 migration is simply the need to test it enough given how extensive the changes are. The problem is, we can't do that migration piecemeal like Mozilla did... Python 2 is 100% dead at this point, so every part of the tree has to be migrated in _one go_ , or nothing will work on systems that lack Python 2. They migrated during a grace period where the harder stuff could be done later while the build system just mostly worked on Python 3... we won't get that luxury and basically have to do this all at once or not at all.\n\n* * *",
  "title": "Platform Development • Re: I created a Python 3 port of UXP out of boredom...",
  "updatedAt": "2026-03-25T17:43:19.000Z"
}