-
-
Notifications
You must be signed in to change notification settings - Fork 536
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
Update external libraries and document their versions #524
Comments
That's a good question. A few months ago, when getting NiceGUI 1.0 ready, I might just have copied the currently stable versions without keeping track of their version numbers. But the upcoming 1.2 release is a good opportunity to get this straight. |
@rodja How do we get the current NiceGUI version at runtime? |
@falkoschindler Maybe with |
... or |
Hi @falkoschindler, Could you clarify the difference between poin t2 and 3 ? Point 3 is a preferred solution I would advocate here because that is a scheme adopted in the web world and CDNs, tools, etc.. are used to it. It would also be easier to automate the dependencies update process if one day that becomes scripted. Also, how about adding a dev version unminified ? That would require an extra key in |
@dclause Yes, with point 2 I primarily thought about the local file system, while point 3 deals with the request API. Actually we thought about changing the current API from:
to
Maybe we also need additional library version numbers. But the point is, we need the NiceGUI version to ensure everyone uses the correct version of custom components like |
Instead of https://nicegui.io/_nicegui/1.2.0/components/aggrid I also like @dclause suggestion of using the schema https://nicegui.io/_nicegui/components/aggrid?v=1.2.0. As @falkoschindler noted it may be simpler to use the NiceGUI version instead of the library version... |
Getting the NiceGUI version Using Cache-proof API (point 3) Especially for 3rd-party dependencies like socket.io.min.js it might be confusing to append the NiceGUI version Using the NiceGUI version instead of the library version has the advantage of less manual work when updating the libraries. The NiceGUI version is incremented automatically and the locally stored libraries are upgraded using a script I'm writing right now. Local storage (point 2) When we don't include the library version in the API (point 3), it is easier to store the files without it as well. Then we can mount the static directory without the need of adding or removing version numbers when looking for files. |
I did not see your last point: indeed having a script to update the libraries would be nice, and rationalize their inclusion and storage. In the meantime, I have opened #542 with stuffs from this issue. It is far from anything ready but I wanted to showcase my idea with the production / development mode files. |
I started to automatically update all dependencies on the branch dependencies. Besides being pretty cumbersome to find all relevant CDNs and the current versions of each package, there are two mayor issues remaining:
These are no showstoppers. But if we promise to upgrade all libraries with every minor version change, we should try to do it thoroughly. The next opportunity might be months away. So it would be very interesting to find out how to include these ESM packages. |
I may be wrong but only some minor difference are visible right ? Namely only the padding of elements in the 'windows style' taskbar right ? That is probably some small adjustements to do in the CSS nicegui.css file. Maybe a stronger CSS selector or explicit padding / margin properties or something that kind. It should be minor though as long as the updates are for minor version bumping. Speaking of that, do you plan also updating the python dependencies ? I have for instance a compatibility issue with nicegui 1.1.11 and fastAPI 0.94.1 on my project. As of ESM modules, I am not sure to understand the issue. ES6 module is supported by most modern browsers https://caniuse.com/es6-module Lastly: will the update script be included in the project ? |
Just check: vue3 does only support modern browsers anyway, so that is the whole premise of nicegui fundamental I guess here: https://vuejs.org/about/faq.html#what-browsers-does-vue-support |
Well, I thought if I notice any visual difference, then there could be larger ones depending on the user code. nicegui.css didn't change, so the cause is probably in Quasar or Tailwind. Of course, fixing the website is not a problem. But we don't want every NiceGUI user to fix his layout after upgrading NiceGUI. I'm not sure about Python dependencies. Maybe we should discuss it on a separate thread. My concern about ES6 modules is primarily based on my lack of JS experience: How do we need to modify the import mechanism (mainly in index.html) to load ES6 modules like https://unpkg.com/browse/three@0.150.1/build/three.module.js? And how to handle libraries like https://cdn.jsdelivr.net/npm/mermaid@10.0.2/dist/ which are fragmented into a thousand files? Again: That's probably solvable, but maybe not on a Friday night. 😉 Yes, the update script lives here (at the moment): https://github.com/zauberzeug/nicegui/blob/dependencies/fetch_dependencies.py |
I discovered a pretty fundamental difference between both Tailwind versions: ui.label('Hello World').classes('text-red-400 text-green-500') On main branch this label is green as it should be, since the green color class overwrites the red one. But after the update the label is red. The new Tailwind seems to sort classes alphabetically. It also causes the colored window buttons to have a default I'll probably should do some research to find out more about this behavior. Maybe we can configure it. |
Ok, the answer to this confusion is given here: tailwindlabs/tailwindcss#10603 As an example, the following labels are both green before the update, and both red afterwards: ui.label('Hello').classes('text-red-400 text-green-500')
ui.label('World').classes('text-green-500 text-red-400') So I guess the new behavior is better. We should live with it, fix the website, and clearly indicate this change in the release note. |
I wonder if we could use npm to automatically fetch all dependencies. 🤔 |
I think in f571ff1 I found a generic solution for the new Tailwind behavior: We used to set classes like My new approach introduces custom NiceGUI classes like As far as I can tell, our website looks good again. We still need to inform the users about the Tailwind upgrade. But the impact should be much less dramatic. Last thought: Browsers need to reload the nicegui.css file to get the new class definitions. But we already planned to introduce the NiceGUI version number in the request path. |
Hi ! I don't know how to adress and answer all the subjects in this topic in a coherent way, so I will adress them in the order of my experimentations. Let me order them by numbers: 1. How to manage dependencies ? My own opinion, NiceGUI is a Python project, aiming at Python developpers. The reasons are: That means I would not recommand to add NPM and Node as a requirement for the project. Yet it does not mean we can't use NPM for dependencies :) First, let me highlight a few stuffs: At the moment, I will provide a npm.py script I have been working on that is intended to update the dependencies version using NPM as a single source of install. It them moves the dependencies to an appropriate sub-folder of their install path (element/lib or static folder). 2. How to handle ESM libraries ? I have no real answser here, but considering point 3, I do feel like anyway we could make distinction between component js files (currently using register_component, for instance the 3. Loading dependencies: Also (I don't know really what others are doing with niceGUI): it seems that you (at Zauberzeug) use niceGUI in robots context (like with rosys). I happen to do it too. NiceGUI is the UI of the python code running my robot. In my case, my code runs on a raspberryPI within the robot, and, by nature of my robot, it is connected to the web. Therefore, serving dependencies from the niceGUI server is actually a bottleneck compared to serving from external CDNs. My client browser's network would be in charge of downloading the assets, rather then my robot server to serve it. Plus, the browser could parallelize those calls much more because they come from different domains. Of course that can't always be the case: your robots may be offline. Hence, it could make sense to provide a CDN option for external dependencies. 4. Optimize the dependencies served Here too, I guess I could POC some solution. 5. Allow external library debug and development |
Very, very interesting thoughts, @dclause! But this issue blew up quite a bit. To be honest: It was originally about serving dev-dependencies and we hijacked it for the whole 1.2.0-dependency upgrade process (because answering your question about the current dependency versions required to get this straight first). Let me try to address the points you mentioned and find a new home for them:
@dclause Would you aggree to open new discussions for points 1-3 and continue discussing point 4 and 5 on the mentioned tickets? I would then concentrate on completing the task list at the top to finalize milestone 1.2.0 for the next release. |
@falkoschindler I guess this ticket originally was me trying to understand dependency management because I had those points in mind. But it goes beyond 1.2.0 for sure. Sorry to bother you with so much considerations and extra work ! |
@dclause No worries! Your considerations are always welcome. Its extra work worth spending. 😉 Regarding Memaid: I restricted Ok, so you will cover point 1 in a PR, points 2 and 4 in a combined POC, and point 5 in the already proposed PR #524. |
The dependencies for NiceGUI 1.2.0 are:
|
Let's discuss these issues over there. See #580 (comment) and #581 (comment). |
I would like to introduce a PR to conditionnally load the external libraries in dev mode because of:
"Vue.js is detected on this page. Devtools inspection is not available because it's in production mode or explicitly disabled by the author."
To do so, I have a question on external library version: which versions are they ?
I can see no mention on external library version in the README.md (which would be a nice addition to read the appropriate documentation). Using that, I would be able to provide the vue.global.prod.js equivalent dev file. I guess one version of this:
https://unpkg.com/browse/vue@3.2.47/dist/vue.global.js
Task list:
Maybe later:
The text was updated successfully, but these errors were encountered: