Reposilite 4.x wishlist #2005
Comments
dzikoysk
added
investigation
|
Since it seems like the UI is going to be majorly reworked: thoughts on adding "looks at least somewhat decent on mobile" to the list? (especially the admin interface, so admin stuff can be done from a mobile device) |
|
also, one note: you mentioned using jte. |
Sure, the mobile support should be way better there. In current UI, it's mainly blocked by the tabs & jsonforms libraries, but it's a minor issue, so I didn't decide to invest my time into it for now.
When I'm thinking about a desired stack for a new frontend, I want to cover these 3 crucial requirements:
The main reason behind JTE choice is performance - it provides a compilation mode, where it generates classes for all template components:
This + a possibility to implement Node-like hot reloading makes it a good candidate. It has some issues tho - writing a JavaScript code inside a template might be a bit painful. Even if HTMX/Unpolly/something similar would cover most of the features, there are still some side cases, when we may need to cover with JS. Raw JS/state management is kind rough, so we could try to utilize something like Preact locally, for some specific features. |
|
The only thing I'm missing is an indexer+search built-in. |
I was working on that for a bit as a plugin sometime ago, and may continue it one day™ (or I might just forgor again) |
|
Maybe not too related to Reposilite. But what about an integrated docker registry? |
|
Yes, the Docker registry would be absolutely great. Unfortunately, it requires a lot of work, as the specification seems to be quite complex - there's an issue for that: It'd be nice to document all things we need to do (from specification perspective), so later on we could try to estimate if we'll be able to do that or not. |
There is already Harbor for that, so I don't think it is strictly necessary. I do appreciate Reposilite's focus on providing great light weight solution for hosting Maven repositories. |
|
Yeah you're right. There is enough software which is already capable of providing a registry and reposilite should stay simple-ish |
|
I'd like to see support for byte ranges. I want to use reposilite as a simple arch mirror, and arch is complaining about failed downloads. |
Well, yes and no. These days, you're often distributing JVM apps as containers, so it'd be kinda nice to have it supported at some point - I could even distribute Reposilite itself there. Of course, it can't be considered as the new main target, because we don't have enough resources to compete with dedicated tools, like e.g. Harbor. Hopefully, something like that should be possible to implement purely as an optional plugin.
It'd be nice if you could submit a new issue with a bit more detailed description. As long as we don't aim to support arch itself, supporting http range requests probably could be a thing. |
|
One thing I would like to see is the ability to customize the appearance |
|
yeah, the ability to provide your own css styles/themes would be quite nice ie. use the default frontend, but just have some customized css (ie. to make the frontend a bit less "harsh") also here's a few misc. things:
~ edit: merged both comments / @dzikoysk |
I'll most likely implement the new frontend with HTMX+Tailwindcss. These sources don't need a build process, so users should be able to pretty much do whatever they want there. I don't think I'll target the appearance that much tho, because it's quite niche feature, but the idea with a separate CSS file for some most common stuff like e.g. colors might be interesting. I think I'll be able to tell more once I'll start doing this, because I'm not completely sure how it should be done yet.
This is already possible - just create a new repository per each mirrored repository and link these local mirrors via local loopback link: You can set individual storage limits per each repo as it'd be a regular repo.
Currently, we're only providing a built-in option to delete snapshot files, but if we'd have an option to determine if a given file was proxied or not, then date based cleanup for mirrors would be a great enhancement. This is not really related to 3.x/4.x, so I created a new issue for this:
It was requested a lot of times - not sure how it'll look like on the new frontend, but in general this is already planned ✔️
I still think that the search option in UI should be implemented internally in Reposilite, based on some metadata we'll store in the database. Speaking about the maven-indexer, we have a separate issue for this: There were some issues with it, if you have some more data on this, it'd be nice to continue this thread there, just so we can keep this in one place.
The problem with detailed statistics is that it highly increases the database usage - that's why we're currently only counting unique requests per month by default. On the other hand, the prometheus integration will be merged into the core sources, so we should be fine with just pushing some extra events instead of storing this on our own. In this case, it's also not important to address this directly in 4.x - extra metrics can be added later as a feature requests.
It wouldn't be a breaking change, so I think it could be moved to a standalone issue if needed. In general, I have a limited time for the project, so such issues usually have really low priority for me, but feel free to submit a PR - it's cool to have such options.
Probably could be addressed after 4.x, but I'll try to remember about this after rewriting the layout.
|
|
Ability to hostdart/flutter packages: https://github.com/dart-lang/pub/blob/master/doc/repository-spec-v2.md |
|
Copying this over here just in case: #1011 (comment) |
As for the UI of Reposilite, I think that using something like Tailwind or UnoCSS would be a good fit. I wonder if there could be a redesign of the way that data was fetched from the backend and the frontend that wouldn't require a templating engine serving the content. I wonder if there is some sort of RPC that existed for generating Web based code from Kotlin types and APIs? If not then a templating engine and a lightweight framework with styling sugar sounds like a good step towards there, as I don't think Kotlin has amazing web features. |
I'm a bit tired of introducing intermediate layers, just to display some sort of static content. Having a template engine, I could possibly get rid of the whole frontend module. There are some drawbacks as always, but as far as I see it could be an option to significantly reduce the size of the codebase, so it'd be easier to maintain it. Another benefit of having the frontend generated by backend is extensibility - currently, there is no option to modify frontend via plugin API, because frontend is just a standalone app that is precompiled earlier. It's even hard to inject custom base path url, not speaking about some more advanced effects.
Even if we'd have some sort of RPC framework, it'd still need to make some calls over the network to fetch/update latest state for client-side logic. It means we're falling once again into the world with 2 independent states (client and server) that we need to synchronize at some point.
I had some time to prototype a basic plugin for Javalin, and it's promising: 7GvUf0FLo5.1.mp4So we can prototype frontend with hot-reloads. Of course, for backend changes we need to rebuild a project, but it's good enough I'd say. |
if you don't introduce any methods/etc. you can hotswap code in intellij when running in debug mode. I personally have a macro set up to execute:
when pressing ctrl + s (you can create a similar macro by starting macro recording, using double shift then searching for and executing each action, and then afterwards edit the macro to remove all the double shifts & other useless stuff) it won't hotswap anything which introduces new methods or new classes, but if it's just a change to the method body, it hotswaps it. quite useful. |
That's perfect yeah! I understand that reasoning. |
I do feel like that for this, if an RPC framework existed, there are good solutions for syncing up backend and client. Even just a simple SSE connection could go a long way for a simple dynamic frontend, and if there was an RPC, all the API infrastructure for the framework side code could be standardized and modified from the backend, without requiring a change to the frontend. Obviously this is easier said than done, but I'd be happy to look into if this is a possible solution, since generally the downsides of a templating engine can introduce limitations in the future, but I think in this case, either solution would work generally well. |
|
As long as we are talking about choices of frontend technology, what about going for a nice "clean" HTMX powered front-end? Backend could use your own favorite templating engine to serve html smippets, so we get best of both worlds -- fast in-place reloads and templated/skinnable frontend. |
afaik, htmx was/is already being considered. (and, from what I can tell, is currently the preferred option) |
|
We've got a decent conversation regarding the 4.x, so I'd say we're close to finalizing the RFCs list. I'll try to refine this in the upcoming month, so we'll have a batter overview of what needs be done. Looking at my schedule, I think the roadmap is still quite up-to-date - the development phase will more likely start in Q3. |
|
So searching for an artifact didn't make it into the list? :( |
|
The RFCs list is not yet updated, but I can already say that some sort of artifact browser should be a part of 4.x :) |
|
As discussed on discord: adding the ability to have the metrics served on another port so you don't need to expose an authenticated endpoint but can just use a docker network to grab the data without auth and security risk |
|
Wanted to comment on OAuth/OIDC: |
|
Just noticed that configuration via environment variables (for docker/kubernetes) is not on the task list for v4 |
|
@Minecraftschurli Complex configuration via environment variables is not something that would work for us quite good - e.g. consider some predefined access tokens, there's no way we can include more advanced details like routes etc. I don't quite like the way Reposilite is configured right now, so it'll be definitely reworked from scratch. My rough idea on how it should work in 4.x:
|
|
everything that is set up through a ui should also be able to be preconfigured using parameters/env/configfiles so installation in cloud environments (docker/kubernetes) is easier |
|
I personally think that a license change (to a non-open-source license) would do more harm (discourage usage) than good. With the recent changes in Nexus OSS (moving towards closed-source, see https://www.sonatype.com/blog/sonatype-nexus-repository-community-edition), you are likely to strengthen your user base and staying open source would be much more welcoming to people coming from Nexus. Just my two cents. |
yeah, I agree I hadn't noticed this before I'm also entirely unwilling license any of my contributions under a non-FOSS license*. (if you want to switch to a different FOSS license, I would be willing to relicense my contributions) *it really depends on the license. if it's nearly a FOSS license, ie. a FOSS license with one or two small clauses that, by technicality, make it non-FOSS, then I'd be willing to consider it. |
I'm doing OSS consistently for over past 10 years and for quite a long time I tend to disagree with this. It's a broader topic, but tl;dr: From my point of view not protecting a project from so called free-riding is what harms it the most, in some really specific way. I'm responsible for maintaining this project on a daily basis and I want to interact with my users, so can I understand their needs - in fact, I want to know everything that is going on with this piece of software directly from them. It doesn't matter if you're a hobbyist, a community, small or big company - as long as there's no 3rd party player between us, you're welcome. Also, the time flies and I have only more and more responsibilities. Cutting out such service providers in the first place leaves me some area to build even more stuff around the project in the future. Eventually, the gains for this community should be incomparably higher than being compliant with what FOSS definition stands for.
The only license I'm considering right now is a FSL (
This change, if I'd decide to do it, would only apply to 4.x. Considering that it's pretty much a full rewrite, it shouldn't be an issue, but of course if you'd find some leftovers I'll do as much as I can to satisfy both sides. |
do you know if currently any companies are even offering reposilite even as a secondary product (ie. offer hosted services, one of those services being reposilite)?
hmm, I'd have to read through it, but I might be fine with that.
there is also the Commons Clause, which you'd add on to any other license (ie. the Apache 2.0 license) I know there are also the polyform licenses, however I have not yet decided my opinion on them.
I was planning at some point to contribute more to reposilite, just because I really like reposilite and want to see it improve. |
Yes, but nothing significant yet. Being responsible requires prior communication, I think that would be harmful to do such change knowing that there's a whole ecosystem relying on you (and history is full of such surprises). I think we should tackle it down in its roots, so we'll never end up in a situation like that in the first place.
That's one of my problems with the "OSS"-compatible licenses - in reality, such license is way more restrictive and affects mentioned hobbyists, freelancers and companies of any size, because it forces them to change the way they work with the project on a daily basis. That's the complete opposite of my intention and I'd hardly argue that it is really "free".
There's no much difference between FSL, Commons Clause, BSL or Polyform. All of them are from the group of source-available licenses and actually FSL is the most permissive one, because it's purely focused on free-riding from SaaS-like services. Any other commercial use you could think of is still permitted + it has the shortest delay time. |
I wonder if it would be possible to put a poison-pill type of thing in a license/CLA saying that it's currently under xyz license, but if any provider in the future offers it as a primary product and earns over $x from it, then it automagically relicenses (for everyone, or just for them, idk) to one of the more restictive licenses (commons clause, FSL, etc.).
fair enough |
Do you want to create a company to offer services around Reposilite? If not, then I don't see the issue. Part of open source is that other people can do useful things with the software including building services on top of it. If that would happen, it would be a success of the project not a threat. If they close the source of their modifications, they become irrelevant. If they keep it open, it gives extra features to pull in or gives ideas to do things better or differently. If yes, then the first thing to do is to attract customers, not to close up the software with a source available license. Closing up will deter potential customers (including my organization) so you will shoot yourself in the foot. Open source software (using standard open source licenses, i.e. what you call "FOSS definition") represents 8.8 trillion USD of economic value. No need to change the game to be successful! |
Like I said, it would be great to build something on top of it in the future. By looking at a FSL I think it's pretty clear what it would be, so I pretty like the transparency we'd get. Also, as long as I would not build anything, this would be just Apache 2.0 as it is right now.
Is your organization building, to be quite explicit, a cloud hosting that sells Reposilite? I'm trying to understand your use-case and concerns, because for me it's like a discussion between minimum wage workers who are trying to oppose higher taxes for billionaires. I mean I get the idea, I'm just not sure if that's the hill we'd like to die on for them 😅
Cashed by the individuals at the end of the food chain :') If that'd be about the money, I could just not do 4.x - maintain 3.x and secretly write something new from scratch. That's not the case, I'm just looking for some options to improve the sustainability of the ecosystem, so we don't have to wait 2-3 years for some issues to be resolved + have some infrastructure around it. I'm actually already paying someone to help me with 4.x and we were gathering this budget for last 1.5 year, mostly based on donations from lovely individuals. If we'd like to stay in this kinda toxic love-hate relationship (but consistent with OSS definition!) I'm fine with that too, but I think eventually you (as a community) are the ones that are losing on this trade. |
|
The default free open source license should be that you can do anything with it except offering it as a paid service or anything profit related. |
The point of FOSS software is freedom as defined here https://www.gnu.org/philosophy/free-sw.en.html#four-freedoms and this has been the case for the past 40 years. Go for a copyleft license if you want more reciprocity e.g. with AGPL. |
No. Just a company considering to move to Reposilite for internal purposes. If software is not open source, it does not pass our selection criteria for internal usage (since it does not respect our freedom in the meaning cited above). |
|
40 years ago, you didn't have SAAS companies abusing open source software I suppose? |
No, but the AGPL was introduced exactly for that reason in 2007 (with some prehistory in the early 2000s - see https://en.wikipedia.org/wiki/GNU_Affero_General_Public_License) |
About
Reposilite 3.x is a stable piece of software and for most of the time it serves you well. Of course, some decisions I made during 2.x -> 3.x rewrite were good, and some of them are a bit of a problem these days. I think that's a good time to start summing up the 3.x release line, so we can prepare for the next major version. Fortunately, this time we're more likely talking about an evolution, not a revolution - the backend module is much easier to maintain, Kotlin really paid off here. Sadly, I can't say it about frontend in JS + Vue 3.
Roadmap
Some high level estimation of a roadmap for Reposilite 4.x 💕
General goals
RFCs
Thanks to all sponsors that decided to support me this year! We wouldn't be here without you 💛
The text was updated successfully, but these errors were encountered: