Override requirements (at a given level) from a requirements file.

[moshez]

In that case, instead of merging, we override

Fixes: #476

PR Checklist:

• [x] All new features have been tested
• [x] All new features have been documented
• [x] I have read the CONTRIBUTING.md file
• [x] I will abide by the code of conduct

[mhsmith]

I would have expected a workflow where create generated a lock file when requirements were installed (possibly requiring a --lock argument); the user could then choose to adopt that lock file by adding it to their pyproject.toml.

That seems a bit awkward. Instead of requiring the user to pick a filename, why not just auto-generate the filename based on the platform and format names? Then pyproject.toml doesn't need to be edited; instead, we have the following scenarios:

• Every command which can install requirements has a --lock option which generates or re-generates the lock file.
• If the lock file exists, it's used automatically in any subsequent commands.
• Maybe we also have an --unlock option to remove the lock file. In that case, the the user would never need to touch the file directly, and its name, location and format would become internal implementation details which we'd be free to change in the future.

I don't have a clear idea of the file's name or location, but maybe we could store it under a briefcase or .briefcase subdirectory of the project. This could be used to store other things which are internal to Briefcase, but should still be checked into version control, unlike build.

[freakboy3742]

I would have expected a workflow where create generated a lock file when requirements were installed (possibly requiring a --lock argument); the user could then choose to adopt that lock file by adding it to their pyproject.toml.

That seems a bit awkward. Instead of requiring the user to pick a filename, why not just auto-generate the filename based on the platform and format names? Then pyproject.toml doesn't need to be edited; instead, we have the following scenarios:

So, one reason is that people can be... unreasonably opinionated about the names they use for their lock files :-)

• Every command which can install requirements has a --lock option which generates or re-generates the lock file.
• If the lock file exists, it's used automatically in any subsequent commands.
• Maybe we also have an --unlock option to remove the lock file. In that case, the the user would never need to touch the file directly, and its name, location and format would become internal implementation details which we'd be free to change in the future.

I do like this as a workflow. My hesitation is around the slightly opaque user experience - "I've added foobar==1.2.3 to my requirements, but it's not getting installed" becomes even harder to diagnose. This is always going to be the case when lock files are involved, but when the lock file is completely implied, there's no evidence in the config file that directs the user's attention to the fact that locking is being performed.

I don't have a clear idea of the file's name or location, but maybe we could store it under a briefcase or .briefcase subdirectory of the project. This could be used to store other things which are internal to Briefcase, but should still be checked into version control, unlike build.

This is where Opinions (tm) get involved :-) The only conventions I've seen around requirements are either (1) in the project root, or (2) in a requirements directory - both are workable here.

[mhsmith]

My hesitation is around the slightly opaque user experience - "I've added foobar==1.2.3 to my requirements, but it's not getting installed" becomes even harder to diagnose.

I think changing the requirements list should always invalidate an existing lock file. We could store the original (merged but unlocked) requirements file next to the lock file, and compare it with the current configuration.

This also touches on the automatic update idea discussed at https://github.com/beeware/briefcase/issues/807#issuecomment-1203354768.

The only conventions I've seen around requirements are either (1) in the project root, or (2) in a requirements directory - both are workable here.

If we do decide that the lock file is an internal implementation detail, I think it should be stored in a directory whose name makes that clear.

[freakboy3742]

My hesitation is around the slightly opaque user experience - "I've added foobar==1.2.3 to my requirements, but it's not getting installed" becomes even harder to diagnose.

I think changing the requirements list should always invalidate an existing lock file. We could store the original (merged but unlocked) requirements file next to the lock file, and compare it with the current configuration.

This also touches on the automatic update idea discussed at #807 (comment).

Ah - the overlap with #807 changes things significantly. I was considering the lock file as something you could (concievably, although you're not likely to) write by hand, in which case manual specification and customisation options make more sense. Having the lock autogenerated on any change to requirements is another matter entirely.

The only conventions I've seen around requirements are either (1) in the project root, or (2) in a requirements directory - both are workable here.

If we do decide that the lock file is an internal implementation detail, I think it should be stored in a directory whose name makes that clear.

Agreed; although the lock file is something that would be checked into version control, so we need to be careful not to make it too hidden; and we need to make sure that it any "#807 state" information that feeds the lock file invalidation process is also storable in version control.

[freakboy3742]

I'm going to close this - it's been almost 2 years since the last update, and the PR has drifted significantly from the current codebase.