The Future of Anvil Community Packages

Hello Anvil Community!

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
    • Similar to https://pub.dev/ is for flutter/dart
  • Create Packages ( package manager)

    • 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

9 Likes

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.

9 Likes

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.

3 Likes

I would definitely add that to the infrastructure. That is, allow for paid packages.

2 Likes

I like it.
Here are a few thoughts:

  • 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.

2 Likes

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?

1 Like

Linking to this related old FR just for reference: Community Projects

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.

1 Like

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.

1 Like

Very interesting thoughts on the matter!

@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.

@hugetim – yes that is true.

I agree that at the heart of this some questions must be clarified:

  • Depend on a certain Version of an Anvil app → already in the pipeline as far as I know
  • Where are the packages hosted and how is it ensured that they can’t be broken/deleted by the author?
  • How can the community work together → “share with the community” @stefano.menci
  • @anvil.central what are your thoght on the matter?

-Mark

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. :clap:

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.

1 Like

Thanks for the feedback, all!

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 :slight_smile: ). 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…

1 Like

@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.

2 Likes

I would say that once you click the Share as community package button, the app remains forever, (or until flagged inappropriate and deleted.)

This would obviously require the Share as community package button, which doesn’t exist (yet?)

2 Likes

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?