[bug#49834] Add dynaconf

[paul]

Dear Sarah,

On 8/29/21 12:46 AM, Sarah Morgensen wrote:
> Did you receive my other email?  I found that in fact none of the flake8
> packages, as well as some others, are actually required.  I apologise if
> merging these bugs caused it to get lost!  I'll quote it below.
No I did not :( . Also I'm sorry about the confusion with the multiple 
bug reports, I forgot to send the patches directly to the ticket address.
> * gnu/packages/python-xyz.scm (python-colorama-0.4.1): New variable,
> (python-dotenv-0.13.0): New variable,
> (dynaconf): New variable.
> > Packages typically get one commit per package (so this would be three
> > commits).
I wasn't sure about this because right now those exact versions are only 
needed by dynaconf. Anyway I divided them in three commits.
> > >   * gnu/packages/patches/dynaconf-Unvendor-dependencies.patch: New file.
> >    ^ an extra space slipped in here.
> >
> > > [...]
> > > +    (arguments
> > > +     `(#:phases
> > > +       (modify-phases %standard-phases
> > > +         (replace 'check
> > > +           (lambda* (#:key tests? outputs #:allow-other-keys)
> > > +             (when tests?
> > > +               (setenv "PATH"
> > > +                       (string-append (assoc-ref outputs "out") "/bin:"
> > > +                                      (getenv "PATH")))
> > > +               ;; These tests depend on hvac and a
> > > +               ;; live Vault process.
> > > +               (delete-file "tests/test_vault.py")
> > > +               (invoke "make" "test_only"))
> > > +             #t)))))
> >                  ^ Nitpick: phases no longer have to end in #t, though it
> >                  doesn't hurt.
Thank you I didn't know it, fixed!
> > > +    (propagated-inputs
> > > +     `(("python-click" ,python-click)
> > > +       ("python-dotenv" ,python-dotenv-0.13.0)
> > > +       ("python-ruamel.yaml" ,python-ruamel.yaml)
> > > +       ("python-toml" ,python-toml)))
> > > +    (native-inputs
> > > +     `(("make" ,gnu-make)
> > > +       ("python-codecov" ,python-codecov)
> > > +       ("python-configobj" ,python-configobj)
> > > +       ("python-colorama" ,python-colorama-0.4.1)
> > > +       ("python-django" ,python-django)
> > > +       ("python-flake8" ,python-flake8)
> > > +       ("python-flake8-debugger" ,python-flake8-debugger)
> > > +       ("python-flake8-print" ,python-flake8-print)
> > > +       ("python-flake8-todo" ,python-flake8-todo)
> > > +       ("python-flask" ,python-flask)
> > > +       ("python-future" ,python-future)
> > > +       ("python-pep8-naming" ,python-pep8-naming)
> > > +       ("python-pytest" ,python-pytest-6)
> > > +       ("python-pytest-cov" ,python-pytest-cov)
> > > +       ("python-pytest-forked" ,python-pytest-forked)
> > > +       ("python-pytest-mock" ,python-pytest-mock)
> > > +       ("python-pytest-xdist" ,python-pytest-xdist)
> > > +       ("python-radon" ,python-radon)))
> > With the test_only target, I think only a few of these are actually
> > required. Also, configobj should probably be a propagated input as
> > dynaconf uses it for ini files. I've attached a patch below.
> >
> > Notably, this seems to make python-flake8-debugger, python-flake8-todo,
> > python-pep8-naming and python-colorama-0.4.1 unneccessary (I think
> > because they are used for code linting, and the test_only target doesn't
> > do linting). WDYT?
> >
> > (Even if they aren't necessary for packaging dynaconf, you're still
> > welcome to send them as separate patches :)
I definitely agree, I'll send them as separate patches.
> > > +    (home-page
> > > +     "https://github.com/rochacbruno/dynaconf";)
> >         ^ Nitpick: this can go on one line
> >         
> > > +    (synopsis
> > > +     "The dynamic configurator for your Python Project")
> >         ^ Likewise
> >         
> > > +    (description
> > > +     "This package provides @code{dynaconf} the dynamic configurator for
> > > +your Python Project.")
> > Even as someone who has used python a lot before, this doesn't tell me
> > anything about what dynaconf actually does or why I might want to
> > install it. (Or, is it even an end-user package?) For examples, take a
> > look at pretty much any package which has more than two lines in its
> > description (like, say, python-seaborn). I know writing a good
> > description can be difficult, but they tend to stick around and read by
> > lots of people, so getting it right the first time is important!

I updated the description with the feature set provided on the main 
website, it should be a little more clear now .


I'm sending an updated patchset, thank you for your time :)


Giacomo