Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Better configuration #20

Closed
icxes opened this issue Feb 4, 2023 · 6 comments
Closed

Better configuration #20

icxes opened this issue Feb 4, 2023 · 6 comments
Assignees
Labels
enhancement New feature or request

Comments

@icxes
Copy link
Contributor

icxes commented Feb 4, 2023

The current way to do configuration using a file is a bit silly and it's not so clear how the various command line arguments (which aren't exactly obvious either) translate to a config file. Comments are pretty much necessary if you don't look at your config too often. Using json/yaml/whatever people use now for configuration would improve readability.

Aside from that, I don't think it currently gives any message if there are config errors (tested by putting gibberish at random points in copyparty.conf, no messages in logs and starts up normally (ideally should probably not start at all))

@icxes icxes added the enhancement New feature or request label Feb 4, 2023
@9001
Copy link
Owner

9001 commented Feb 4, 2023

yeee i guess you're right, I'll see what I can do about it, thx

@9001
Copy link
Owner

9001 commented Feb 5, 2023

ok so catching errors is no problem, and some other quick improvements given a slight modification of the example config as input:

but that doesn't really fix the esoteric syntax...

playing with the config generator a bit to try some variations, maybe something like this would be better? the parser would understand both the old and new format, so could keep both for a while

i had a look at toml and yaml -- toml is a bit wordy, each volume entry would be something like

[[volumes]]
fs = "/mnt/music"
share = "/music"
  [ access ]
  rw = "alice bob"
  r = "*"
  [[ flags ]]
  e2ts = true
  hardlink = true
  fk = 4
  [[ flags ]]
  mtp = ".bpm=~/bin/audio-bpm.py"
  [[ flags ]]
  mtp = "key=f,t5,~/bin/audio-key.py"

and i still don't understand yaml but this was suggested by a json-to-yaml converter and it validates at least:

global:
- i: "127.0.0.1"
- p: "80,443"
- z: true
accounts:
  alice: "hunter2"
  bob: "fgsfds"
volumes:
  "/music":
    fs: "/mnt/music"
    access:
      rw: alice bob
      r: "*"
    flags:
    - e2ds: true  # enable file indexing
    - hardlink: true  # dedup with hardlinks instead of symlinks
    - fk: 4  # enable filekeys, 4 characters long
    - mtp: ".bpm=~/bin/audio-bpm.py"  # detect music bpm
    - mtp: "key=f,t5,~/bin/audio-key.py"  # detect music key

which is the same as this in current copyparty syntax:

-i 127.0.0.1
-p 80,443
-z

u alice:hunter2
u bob:fgsfds

/mnt/music
/music
rw alice bob
r
c e2ds,hardlink
c fk=4
c mtp=.bpm=~/bin/audio-bpm.py
c mtp=key=f,t5,~/bin/audio-key.py

or converted to the "new" format,

[global]
  -i 127.0.0.1
  -p 80,443
  -z

[accounts]
  alice:hunter2
  bob:fgsfds

[/music]
  /mnt/music
  [acc]
    rw alice bob
    r *
  [flag]
    e2ds,hardlink
    fk=4
    mtp=.bpm=~/bin/audio-bpm.py
    mtp=key=f,t5,~/bin/audio-key.py

yaml looks fairly good,

  • drawback: some things need quotes but others don't (just adding quotes everywhere might be ok)
  • drawback: when to add a - or not is extremely confusing at first, but might be fine given enough examples
    • tho the same thing could be said for the current syntax
  • advantage: it has inline comments, but that should be possible to add to the existing syntax too if someone would find it useful
  • doesn't support tabs, but i'll add that + support for %includes if it seems like the best approach

unfortunately don't think it'd help much against the volflag syntax though, so parts of it would still be crazy

maybe proper documentation would help a bit as well? since currently --help / --help-flags are the best references for knowing which args / volflags are available

@icxes
Copy link
Contributor Author

icxes commented Feb 5, 2023

I don't really have any opinion on what's better than the other, but they're all more readable than the current one, so lgtm

@9001
Copy link
Owner

9001 commented Feb 5, 2023

aight, think i'll go for something based on the bottom example (so not yaml) plus some good documentation to go with it 👍

current idea (all indentation is optional / insignificant):

[global]
  # can contain any argument listed in --help
  i: 127.0.0.1
  p: 80, 443
  zv, qr, force-js

[accounts]
  alice: hunter2  # inline comments are OK if there is
  bob: fgsfds     # at least two spaces before the '#'

[/music]
  /mnt/music
  accs:
    rw: alice, bob
    r: *
  flags:
    # can contain any argument listed in --help-flags
    e2ds, hardlink
    fk: 4
    mtp: .bpm=~/bin/audio-bpm.py
    mtp: key=f,t5,~/bin/audio-key.py

9001 added a commit that referenced this issue Feb 5, 2023
9001 added a commit that referenced this issue Feb 7, 2023
@9001
Copy link
Owner

9001 commented Feb 7, 2023

new config syntax has been added, and the parser is fairly strict yet helpful -- much less confusing than the old one 🤞

the config explainer (--vc, screenshot) will hopefully help if copyparty does something unexpected, and --cgen can be used to convert the current config into config files (probably buggy)

old-style configs will be autoupgraded to v2 (but not written back to disk); you can see the upgraded version by adding argument --vc and copypaste that back into the config-file to upgrade it proper

beta is available at https://ocv.me/copyparty-sfx.py -- release this weekend if everyhing seems fine o/

@9001
Copy link
Owner

9001 commented Feb 11, 2023

shipped in v1.6.4 🎉

@9001 9001 closed this as completed Feb 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants