Note: All thoughts expressed below are personal opinions.
Development platforms and frameworks often rise and fall with their communities.
In order for Anvil to grow to its full potential, the way in which the community can develop their own packages must be simplified.
Of course there are already some excellent packages e.g. anvil-extras. However the way to create and manage a package is not quite anvil-style.
Below are some thoughts on how such a thing could be accomplished.
The Anvil landing page gets a new header menu called “Packages”
Packages is a central place (essentially just a webpage) where people can:
Search all Anvil community packages
Like, comment and check the documentation for the packages
In the editor there is a service which is called “package manager” (similar to user service)
This Service allows you to publish the app as a package as well as adding package relevant data e.g.:
You develop a package in the editor as you’d normally would
Once you are done with a certain version → click on package manager → publish → specify version name(V0.0.1) → publish to package manager
After that anvil creates a clone which is then hosted on the package manager space and cannot be changed from the package issuer
(This ensures that no package issuer can accidentally mess up/delete a certain version)
Using Packages
Packages can be imported through the usual dependency manager in the editor.
Difference is that you can specify a certain version e.g. anvil-extras ^1.6 or to simply follow the newest version
Packages can be cloned from the package manager if this option is enabled by the issuer
Working together on packages
Since the codebase is a “normal” anvil app the issuer could simply invite members to start contributing right within the anvil editor.
In a second step the collaboration could be enhanced by:
Adding pull requests
Allowing an anvil app to be open source (i.e. everyone with an anvil app is a contributor)
Or → adding directly to the underlying git-repo
This is simply an idea which obviously needs further refinement.
However this is a step which would bring anvil to the next level - and this is definitely something we as a company would strongly stand behind.
Looking forward to your thoughts on the topic!
Mark
For me, the most important point of these is the ability to pin a dependency version. It’s been mentioned before and I believe it’s in the pipeline.
There’s one big difference between what you’re describing and the example at flutter: the flutter favourites are curated. You can’t just write something and publish it to that list.
So, one question for me is: who are the curators for this? Anvil? Some subset of the community? Nobody?
Only by answering that do I think this can move forward as everything else hangs on it.
Just in case I sound too negative - these are great ideas and certainly an area where improvement is possible. It’s why I created anvil-extras in preference to the component library.
Some observations…
If anvil curate the library, they become a bottleneck. That’s exactly what happened with the component library.
@stucork and I aren’t exactly overwhelmed with offers of help. We’re in danger of becoming the next bottleneck. (I perhaps already am).
In the end, to do this properly, somebody needs to fund it. I’m doing enough for free already. It won’t be me.
Anvil itself being the most fundamental dependency of the lot…
Not sure whether Anvil should have a single, overall version number, or a per-feature version number. The latter may be more helpful for library/component writers.
If there were a repository of repositories, that’s where I would go looking for the module/app/dependency I am looking for. Now I can only use third party dependencies if I know about them
Anvil-extras is great and it’s growing steadily, but I’m afraid that its very growth in the long term could be a scalability problem. Having this package index would allow to split the one big Anvil-extras into many small apps and make it infinitely scalable
At first I thought that mentioning the Anvil loading page was useless. Then I saw @owen.campbell’s mention of the component library and I changed my mind. I never paid attention to the component library because it is not reachable from the home page. And I wouldn’t create a dependency to any of those apps because I don’t trust that they will stay there and never change
What about (almost) nobody?
A minimum requirement for the apps to appear in the index could be some sort of documentation. For example a readme.rst uploaded in the assets.
Users could thumb up apps to push them higher in the list or report them for removal.
The Anvil team or a group of moderators would decide whether to remove a reported app.
Some apps need bet-your-business reliability and support from their third party components. Many don’t. To grow, this repository would need both.
Edit: I just had a crazy thought. Instead of a Feature Request, what about a “bake-off”? Mock up an Anvil app that shows how your repository idea would work?
I wonder whether a practical barrier to the way you are envisioning working together on packages is that collaboration within the Anvil IDE is currently a paid feature that requires the Business Plan or higher.
This type of collaboration would require a change in the way apps are shared.
Right now you can only share apps with other members of your account, but, for this to work as described, apps would need to be shared among users of different accounts. Whether to allow users in the free plan to edit shared apps, it’s up to Anvil to decide.
One way to do this could be a Share as community package button next to the Share with other members of your team one.
One way to manage this kind of app sharing could be to make shared apps editable by all users, every user would edit their own branch, only the creator or a list of maintainers would be able to merge to the published branch and create new versions.
@owen.campbell
Yes flutter favorites are curated, however in general anyone can publish packages to pub.dev and only some are selected.
Curated “favorites” would be optional and could be done by anvil if they wish. See this Guide for more info: Publishing packages | Dart
Generally speaking the likes and usage of the community would “curate” the library. Mechanisms like sponsoring or payed packages could then ensure further development.
@p.colbert
A bake off does not sound to crazy to me. Actually I think I’ll try to stich something together this weekend.
In the realm of separation of concerns… Look-and-feel is one thing. API is another. When I can, I like to think of the API as a foundation for the UI. It really helps make the entities, relationships, queries and operations concrete.
If those terms suggest a database model, that’s intentional. Packages are persistent entities, after all. Their content and metadata should be, too. Perhaps an ER model might be a good start?
Great topic. It’s really hard to collaborate on Anvil projects. We’ve developed some reusable stuff in several projects that we’d love to share, including some interesting UI components, and bindings to use Google Firebase services from the client, but we couldn’t find an easy way to publish them, while providing the ability to manage versions and updates. We can’t even manage them internally very well. I really admire @owen.campbell for publishing Anvil Extras.
For me the core capability is the machinery to package and publish an app containing code and/or components in such a way that it can be imported into any other Anvil app (in any account). Anvil already has some of the machinery to support this: I can attach another of my own Apps as a dependency, and import its code. So what’s missing?
The main thing seems to be the ability to attach someone else’s app as a dependency (without cloning it, which is useless in the long run): There is no shared Anvil app repository. If we could solve that, I think we’d have something. Versioning and immutability (so published packages can never change) would be key features.
I’m not sure such a repository needs to be curated, or support purchases. Those are certainly interesting ideas, but most successful code repositories don’t do either of those things.
One update for @junderhill - we’ve started to make progress with third-party dependencies! There are publicly importable apps that can be depended on from anywhere (with anvil-extras being Patient Zero here ). If you’d like an app of yours to be given the same treatment, drop us a line at support@anvil.works with the ID of the app itself and we’ll get you set up!
Versioning currently uses the classic Dev/Published system. Watch this space…
@meredydd - what happens if the publisher of a third party dependency leaves Anvil? Does the app go as well or is there some way of future proofing that?
For example, if - god forbid - @stucork were to vanish with the tabulator control, I’d be up a certain watery way without an essential implement.
edit - that’s probably a bad example as he’s probably on an Anvil account that would survive him anyway, but I’m sure you get my point.
Thanks, Meredydd! Would we have to shadow it in a stand-alone Git repo, or could we leave it where it is? Is major/minor version numbering in the works?