Closed FlorianCassayre closed 2 years ago
Oh nice, I've been meaning to do that for a while, but never found searched how to automate the windows build.
That said I'm not sure if this library is actually needed since the standard json
Yeah indeed; I've found demjson to be much much faster in multiple conditions. I always use it in projects involving JSON, but arguably it could be replaced with built-in json module.
I see it moves the win executable to the root, does it also remove the dist/
directory created by pyinstaller?
Can this be utilized to release to homebrew for Mac also?
On Dec 15, 2021, at 9:20 AM, Olivier Cloux @.***> wrote:
Oh nice, I've been meaning to do that for a while, but never found searched how to automate the windows build.
That said I'm not sure if this library is actually needed since the standard json
Yeah indeed; I've found demjson to be much much faster in multiple conditions. I always use it in projects involving JSON, but arguably it could be replaced with built-in json module.
I see it moves the win executable to the root, does it also remove the dist/ directory created by pyinstaller?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.
Yeah indeed; I've found demjson to be much much faster in multiple conditions. I always use it in projects involving JSON, but arguably it could be replaced with built-in json module.
Alright, no problem then; it's just that the original repository hasn't been updated in a while.
I see it moves the win executable to the root, does it also remove the
dist/
directory created by pyinstaller?
It doesn't, but that doesn't matter at all because everything happens in a VM environment, which has nothing to do with the repository. So basically there are no side-effects, except the ones we explicitly do on purpose (like uploading artifacts).
Can this be utilized to release to homebrew for Mac also?
Yes, definitely, and there has to exist tools (GitHub Actions, Docker containers) to help with that.
(however given that I'm not a Mac user, I'll leave this task to someone else)
That said I'm not sure if this library is actually needed since the standard json module should achieve pretty much the same task.
I personally doubt this, because the format of Object
in JavaScript is different from object in json (keys are double-quoted). I remembered I did try to replace demjson
with the built-in json library, but clearily it cannot handle that difference.
PS: BTW, maybe implementing the metadata extraction in BeautifulSoup
or browser emulators (like selenium
or puppeteer
) is a better idea (#11)...
Ah, right, I missed that it could do that. Then json
certainly won't help!
maybe implementing the metadata extraction in BeautifulSoup or browser emulators (like selenium or puppeteer) is a better idea
As long as we can't make a build with sensibly the same size, I object to that. There is no need for complex DOM handling, and all of those libraries are insanely heavy. I want zoomdl to keep a relatively low footprint, and avoid making it unnecessarily large.
I want zoomdl to keep a relatively low footprint, and avoid making it unnecessarily large.
Yeah, I agree. As long as there is no new "must-have" feature that needs those DOM processing, regular expressions are good enough.
This PR aims to simplify the release process by automatically building and uploading the artifacts thanks to GitHub Actions. This should also make the builds more trustworthy & reliable, and additionally remove the need of versioning them in Git.
The principle is simple: when a release is created on GitHub, the workflow will be automatically triggered and after a minute or two the newly generated artifacts will be attached to that release.
Here is an example run of the workflow, and this is the corresponding release that triggered it.
For compatibility reasons I bumped
demjson
(unmaintained) to a somewhat trustable fork,demjson3
. That said I'm not sure if this library is actually needed since the standardjson
module should achieve pretty much the same task. I rapidly tested both binaries, and they seem to be behaving no worse than the ones built locally until now, which suggests the Action is correctly doing its job. The filezoomdl.spec
is required by thepyinstaller
Action, so we should not remove it. Also worth noting that the Windows build scriptwincompile.bat
is not used by the Action.Feedback is welcome.