Save a Build with custom package versions

Feature Requests
1

Scenario:

  • I have a bunch of custom packages set to ‘latest’
  • Pip figures out which versions to install
  • At some point, the build is restarted since Anvil apps do that, and my code breaks because of breaking changes in some custom packages.

Solution:

  • Save a build in the form of a requirements.txt for all specified custom packages, and the dependencies that end up being installed.
2

I believe this is why you get to specify the version of each package.

Edit: It looks there is an option to let you edit requirements.txt.

1 Like
3

Yeah, tried that. Unfortunately I don’t know what the required versions are beforehand, and pip works that out for me. I need to wait for that to resolve first.

Locally, I can just export existing environments to a requirements.txt and I’m looking to do that with Anvil.

4

I use Anvil’s git integration to keep a local copy of my repository. I don’t know what that local copy would look like, though, with user-installed packages. Would you also get a copy of the packages, so that you could generate your own requirements.txt?

Probably not; Anvil runs on Linux, while I run on Windows. Any package binaries would necessarily be different. What we would need is a way to get Anvil’s pip to generate a requirements.txt file on command, i.e., pip freeze > requirements.txt.

When it does build, it may list the package version numbers you need. If so, then you might force a rebuild, in order to get that information.

1 Like
5

So, this may be an under-discoverable feature, but if you enter a package name and then focus the version field, Anvil will actually consult the PyPI index and show you all the available versions:

image

Picking the latest version (2.14.0 in this case) will produce exactly the same results as leaving it blank - at least for the first build - but subsequent builds won’t suddenly pick up a new version.

1 Like
6

If I have 10 custom packages and set them all to “latest”, will it get the latest package for all of them?

My understanding is that if you leave the versions blank in the requirements.txt, the dependency map may result in some packages and dependencies which are not the “latest”. At least that’s what pip does.

What I am currently doing is looking at the console output when a build (with all packages as “latest” ) is completed, writing down all the versions, and I use that as a guide to specify my versions.

7

You are of course right here - if package A you’re installing requires a particular version of package B, and you left the version blank for package B, then you’ll get package A’s version of package B. But if package A already includes package B in its dependencies, there’s no need to include it in your requirements! (Unless you’re using package B directly and want to make sure you’re using a version with the features you need…but then this discussion becomes moot, because you should be specifying a version :slight_smile: )

Regardless, if you want a build that doesn’t change when you redo it, you’ll need to include version number specifications - and usually “pick the latest” is a good start.