Re: How to handle .in files during development

[Gary E. Miller]

Yo Martin!

On Wed, 21 Oct 2020 17:20:03 +0200
Martin Laabs <Martin.Laabs@tu-dresden.de> wrote:

> some parts (e.g. the ubxtool) are provided as .in files in the git 
> repository which are converted to e.g. .py files during the
> installation.

Or, as is the case with ubxtool, not a .py file.

> My problem with that process is if there are changes required in the
> .in files. I could make all my changes in the (auto generated) .py
> file,

Pretty hard to do, the generated files are read-only.

> test it, convert the .py file into a .in file manually

Creating a .in file from the generated file is non trivial and error prone.

> and
> commit a big blob.

Lost me.  What big blob?  You were talking about two simple text files,
nothing blobby about them.

> Obviously, this is not a good programing practice.

Yes, so don't do it.

> The other way around would be: configure scons to convert the .in
> file prior each run to a .py file and run that file.

Whcih is the present configuration.

> However - this
> has the drawback that each change, accidentally made in the
> auto-generated file is lost

Which is why the auto-generated file is read-only.  You have to work hard
to fight the system.

> and has some issues with code editor as
> well.

Really?  Never heard or seen of anything like that.

> (E.g. an exception is raised, the editor jumps to the line, you
> fix it and re-run the program just to see that it had no effect as
> the file was overwritten again ...)

After your editor waves a red flag at you and says: don't edit this file!

Why do all that to avoid typing in a line number by hand?  It is not
costing you any time penalty.

> Is there is a best practice how to deal with this situation?

I am aware of no suggested improvments to the current process.  The .in
files are relatively new so I expect improvements will surface, but no
idea what they might be.

I just keep the .in file I'm working in open all the time.  Change, "scons",
test, repeat.

The reason for this new workflow is that distros can't seem to agree on
what a Pure Python file should look like.  So gpsd has to build them as
required by the local platform.

RGDS
GARY
---------------------------------------------------------------------------
Gary E. Miller Rellim 109 NW Wilmington Ave., Suite E, Bend, OR 97703
        gem@rellim.com  Tel:+1 541 382 8588

            Veritas liberabit vos. -- Quid est veritas?
    "If you can't measure it, you can't improve it." - Lord Kelvin

pgpF9zU4kxoik.pgp
Description: OpenPGP digital signature