Does this project need to be forked?

[WolfgangFahl]

Since there was no reply to #373 i'd love to know whether this project is stale and needs to be forked.

[elimintz]

Haven't had much time in the last months to work on this project. If you would like to fork it and have more people work on it, please feel free to do so.

[WolfgangFahl]

@elimintz thx for the swift reply. A simpler way would be more invites as proposed in #373. I'll e.g. happily improve the continuous integration of the project

[elimintz]

The project does not have automated testing. Writing tests is something I had on my list of things to do, but because justpy is also a user interface, writing tests would require using a headless browser and be quite a big job. Without the automated tests, how will the continuous integration be done? I may be wrong about this, so please let me know what you think.

[WolfgangFahl]

Personally i think some refactoring in the style of "design for testability" would be needed. That means that there should be better separation of concerns between UI parts, synchronization of backend and frontend and the transport protocol.

For the rc-dukes self driving vehicle project in java we had used https://vertx.io/docs/vertx-core/java/ and https://reactivex.io/ as infrastructure projects which show how nicely such a separation of concern and cross platform approach can work. Making javascript, python, java and other technologies work together as seemlessly as possible is something i am interested in from my software engineering and software architecture background. JustPy is a very valuable step in this direction and i think it should be build on and extended to make it a serious contender.

[elimintz]

What you are suggesting is very interesting and would be a major improvement to justpy. It would also require extensive changes in justpy if I understand correctly. I have no experience with the technologies required so most probably cannot contribute much to the effort. I am perfectly fine (in fact think it would be great) with you forking the project and continue working in that direction including inviting more people to work on it. Once you have the first working version, I would be happy to explore how we merge the two projects. I use justpy for my projects and need to be able to make quick changes in a code base that I am familiar with and if these changes are general enough, incorporate them with the public github version. That is why I prefer that the extensive changes be implemented on a fork of the project first.

[sandeep-gh]

Have been wanting to share this for while -- I have a fork of justpy that I am working on. Its open source. Over time many additions/changes got into the fork. These are highlight level changes:

• It uses a functional/bottom-up approach as opposed to object oriented approach (top-down approach). It makes building out plugable components a little bit easier. There are a couple of other benefits.
• tailwind classes are baked in as first class python objects instead of using string. This helps makes manipulation a little easier.
• use Starlette routing so that reverse url lookup can be done
• currently adding support of authentication etc.

[WolfgangFahl]

@sandeep-gh could you please share the link to your fork?

[freemant2000]

But then why not grant more people (trusted developers) commit right to this project?

[WolfgangFahl]

@elimintz already explained that he needs the code base himself for rapid/agile changes that are only based on his own project needs. So one option would be for Eli to fork a clone for himself (e.g. under a different account) and keep this repository intact as it is well known as the community gathering point and could keep the reputation. Another option would be to simply work with different branches.

[falkoschindler]

I'm also very interested in JustPy taking steps towards improving its overall development process, including more people contributing, continuous testing etc. As our UI framework NiceGUI builds upon JustPy, we depend on an official PyPI package instead of custom forks that are not easily available as a dependency. And I think JustPy would greatly benefit from multiple developers working on a common main branch instead of separate forks. Writing Web-UIs with Python is such a great idea and opportunity - I really don't want to see the JustPy repo becoming stale. 😟

[elimintz]

I have no problem freezing justpy as is and endorsing and contributing to a new project, justpy2 (for example) that will support continuous integration and multiple developers. I would be happy to contribute as needed to such project, but not to manage it or be responsible for it.

Once the first stable version of the new project is released, I will make the justpy repository on github private, remove the justpy package from PyPI and also provide the new project management access to the URL justpy.io so the documentation will accessed the same way and users will not be confused. There will be only one public version of justpy and one official package, the new one. In short, I will do whatever it takes to make the transition smooth and easy.

The proposed new direction would be very good for justpy. I am just not able to commit the time and effort to be responsible for such a large change, especially when I don't have the required experience. As with any project, there are risks, so what I am suggesting would provide a fallback in case the new direction meets unforeseen problems.

[sandeep-gh]

Folks, these are the repos related to justpy fork. A detailed discussion is best in a separate thread. Just wanted to mention it here as some aspects are relevant to this discussion.

1. https://github.com/sandeep-gh/ofjustpy
2. https://github.com/sandeep-gh/justpy/tree/with_svelte
3. https://github.com/sandeep-gh/ofjustpy_extn
4. https://github.com/sandeep-gh/ofjustpy-react

These are main changes/extensions:

1. A session manager and uicontext to track and organize htmlcomponent assets. This is useful cos it lets create
   components organized by app semantics and assembled later by layout semantics. For e.g. all buttons can be in button uicontext and then placed at different location based on layout requirements.

2. Use of svelte for frontend rendering: Begin a non-native to javascript world, I found Vue a bit hard to work with. There are few minor kinks but svelte is easier to build components with.

3. Wrote a couple extensions. One takes json/addict and turns it into hierarchical navigation widget.

4. ofjustpy-react is bit experimental. It is an attempt to explicitly declare transitions in the webapp when changes happen at the ui on frontend.

5. Adding support of routing, authentication using Starlette library.

These are couple of minor additions too. But these are the major one. For a demo code see: https://github.com/sandeep-gh/ofjustpy

[frwkl]

Hello everyone, I have been working with Python in the backend and Vue with Quasar in the frontend for a few years. Now I have tested Justpy and find the approach very good. @elimintz thx for the nice work. I would like to get involved in a future project. But in my opinion, Vue is the best choice as a frontend system here, sorry but i love Quasar.

[WolfgangFahl]

see #406 - invitation to first justpy community meeting this friday.

[frwkl]

At this time I unfortunately have a business appointment.