Replies: 9 comments 3 replies
-
That config.py mechanism clearly sucks and should be refactored. Config data should not be in source code. It could be in a plain text file, .ini style, or json encoded. I'll see if I can get some time over the weekend to mess with it. Are you planning for Winter Field Day? |
Beta Was this translation helpful? Give feedback.
-
Yes definitely using it for Winter Field Day. I run both the dashboard and the headless script to feed the images to our website.
Rather than the format, it’s a case of where the file is in the repo. If the file was there but .ignored, then we could reference it in the instructions but not have it be updated. Would that work?
… On Dec 10, 2024, at 8:48 AM, Jeff Otterson ***@***.***> wrote:
That config.py mechanism clearly sucks and should be refactored. Config data should not be in source code.
It could be in a plain text file, .ini style, or json encoded. I'll see if I can get some time over the weekend to mess with it. Are you planning for Winter Field Day?
—
Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6TWSXNZPBRYSM7I76RVW32E3WKPAVCNFSM6AAAAABTLGC4OWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJSGEZDQMY>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
-
I just checked my git status and another example is that I changed the logo.png file. It shows up as a change.
I have no researched this enough regarding git but there should be a way to have files in the repo for the first time user to be able to download but the files are under version control so they do not get in the way of commits. I am not sure what the right pattern is for that…As you said, maybe a template.
If .gitignore has *.png (and *.db) in it, when I get the entire repo the first time do I still get the files? I think yes but I have not tested it yet.
If that works, then having the config.py file in the .gitignore file may be the easy thing.
Tom
… On Dec 10, 2024, at 8:55 AM, Jeff Otterson ***@***.***> wrote:
yeah, probably need a template for it in Git, and instructions to copy and edit the template.
—
Reply to this email directly, view it on GitHub <#67 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC6TWSVNRQBH52KQP57TRID2E3XF3AVCNFSM6AAAAABTLGC4OWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJSGEZTONY>.
You are receiving this because you authored the thread.
|
Beta Was this translation helpful? Give feedback.
-
Would something like configparser work? I am loathe to suggest configparser's INI format but it there is not much of a learning curve to anyone using it. And to handle the GIT issue, do we just put a file called config.ini.sample in the tree and update the INSTALL doc to say copy config.ini.sample as config.ini? And then add *.ini to .gitignore? Use whatever extension you like (or just make a config folder and gitignore that entire folder. I could see something like this:
|
Beta Was this translation helpful? Give feedback.
-
OK so I started on this change. What is the right way ("python way") to handle this? As there are multiple modules and each module needs some of the config, is it better to load the configs into a single dictionary and call the configparser code once to load that dictionary? But then each module would need to access this global/shared dictionary. This would be a singleton pattern to load the config dictionary. This would be a single config.py or global.py that is run once upon startup, then get the dictionary items? I know lots of ways to handle this but wanted to check the python way. :) |
Beta Was this translation helpful? Give feedback.
-
I haven't looked at this for a while, but I think if config.py contained a class "Config", which had all the existing variables that are defined in config.py as properties of that class, and the init method loaded from config.ini (tomllib or configparser) that might be the least intrusive.
callers could instantiate:
that might work. |
Beta Was this translation helpful? Give feedback.
-
99% done I believe. It is in this fork: https://github.com/ny4i/n1mm_view but I am not quite ready to do a PR yet. I took out the ini file name from the class instantiation to get the Singleton to work. But I am not sure it makes sense to add back. Chicken and the egg problem. Changing the name of the ini file requires a change to the code and that would in turn cause a mismatch when syncing to the repo. That was my whole reason to start thinking about this change. I want to give it one more pass to see if I need to add anymore error handling and test it with dashboard too. But if you want to see what direction I took, take a look at the fork. |
Beta Was this translation helpful? Give feedback.
-
I should add that config.ini is in my fork but when you modify it, it should not be considered a change since it is in .gitignore. I also excluded the .db file and the logo file. Basically, I am trying to get it so I can have a running system on the PI I bring to FD and go a git pull before I go, test it out and that't it. That was my reasoning to exclude things that I consider user modified data (versus code). After I get the PR submitted, I will have another change to updates some info in constants.py to add a few modes. Sometimes I have seen SSB, USB and LSB sent as well as MFSK and FT4 so I wanted to handle all those in the modes array. But that is later keep these changes discrete. |
Beta Was this translation helpful? Give feedback.
-
Don't update matplotlib to 3.10 -- that will break some stuff -- as I found
out this morning. I know how to fix it.
…On Sun, Dec 15, 2024 at 4:09 AM Tom Schaefer ***@***.***> wrote:
I should add that config.ini is in my fork but when you modify it, it
should not be considered a change since it is in .gitignore. I also
excluded the .db file and the logo file. Basically, I am trying to get it
so I can have a running system on the PI I bring to FD and go a git pull
before I go, test it out and that't it. That was my reasoning to exclude
things that I consider user modified data (versus code).
After I get the PR submitted, I will have another change to updates some
info in constants.py to add a few modes. Sometimes I have seen SSB, USB and
LSB sent as well as MFSK and FT4 so I wanted to handle all those in the
modes array. But that is later keep these changes discrete.
—
Reply to this email directly, view it on GitHub
<#67 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AEL5GZCQ5O3ITN3XKGZ2EN32FVBL5AVCNFSM6AAAAABTLGC4OWVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNJXGA4DCMQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I have been meaning to ask this...One thing I notice is that since my config.py is of course different than the one in the repo, before a git pull I get a warning about overwriting (paraphrasing) that file. What is the right way to tell git to ignore that config.py is different and get the rest of the files (but leave config.py alone).
I was thinking to add it to .gitignore after the initial git pull but was not sure if that would work.
Beta Was this translation helpful? Give feedback.
All reactions