behavior of pretext init --refresh

[Alex-Jordan]

These are some observations where it looks like output feed from the CLI could be cleaned up.

I ran pretext build on the showcase article, and the CLI shows:

warning: Project's CLI version could not be detected from `requirements.txt`.
warning: Try `pretext init --refresh` to produce a compatible file.

OK, so I run pretext init --refresh. This time:

warning: Project's CLI version could not be detected from `requirements.txt`.
warning: Try `pretext init --refresh` to produce a compatible file.
warning: The `pretext init --refresh` command will be deprecated in a future version.  You can use `pretext update --force` instead.

1. Since I am running pretext init --refresh, it's odd to be told that I should run pretext init --refresh.

2. Also now there is the note about this being deprecated in the future. Should the first message have directly suggested I use pretext update --force?

3. Now maybe the biggest concern. This clobbered the project.ptx file. It removed all the targets and replaced them with just the default "web" and "print" targets. Since this was the showcase article, it's easy to see the diff and restore those targets. And I see that project.ptx.bak exists now. But I feel like the casual suggestion to use pretext init --refresh in the first place should come with a warning that this would kill all the carefully designed targets. Or there should be a different way to narrowly address the original requirements.txt issue that does not involve messing with the project.ptx file.

4. Lastly, it seems there just is no requirements.txt file for the showcase article in the pretext repo in the first place. Is this a file that should be added to the repo? Or more to the point, what should be done to the pretext repo so that running pretext build just works cleanly out of the box?

[bnmnetp]

Yes, #3 has happened to a few people I know and it was very frustrating for them.

I must admit that I do not refresh, I do not update the requirements.txt file, I simply ignore the warning.

I feel like specifying the version of pretext using syntax similar to the python toml file would be more flexible and lead to less warnings. By default the version of pretext could be initialized to "^2.0" meaning any release > 2.0 and < 3.0.

Then the user could be alerted if a new version is available in that range. If a person wanted to pin their project to a specific version of PreTeXt they could use the "2.32.2" syntax to specify an exact version.