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

Introduce global config #236

Closed
abravalheri opened this issue Jul 15, 2019 · 4 comments
Closed

Introduce global config #236

abravalheri opened this issue Jul 15, 2019 · 4 comments
Labels
enhancement New feature or request

Comments

@abravalheri
Copy link
Collaborator

abravalheri commented Jul 15, 2019

Since PyScaffold users probably use putup to create new packages in a recurring basis, it would be nice to allow them to "save" their favourite options somewhere.

Proposal

The create_project function could deep merge the arguments coming from the current sources:

  1. Global configuration file (or file specified by an --config PATH flag)
  2. Local setup.cfg (or maybe pyproject.toml like everyone seems to be doing nowadays?)
  3. Given arguments (via cli or direct api call)
    (in order)

Additionally a flag --save-config could be used in any putup invocation to save the given parameters to the global config file (to bootstrap the config file creation).

Global Config File:

Something following what PyScaffold already does with per-project setup.cfg, but in a global location:

  • OSX: ~/Library/Preferences/pyscaffold/default.cfg (or something like that)
  • Windows: C:\Users\<username>\AppData\Local\pyscaffold\pyscaffold\default.cfg
  • Linux/Others: $XDG_CONFIG_HOME/pyscaffold/default.cfg with fallback to ~/.config/pyscaffold/default.cfg
    (Please check appdirs for more info).
@abravalheri
Copy link
Collaborator Author

abravalheri commented Jul 15, 2019

Example of possible config file:

[metadata]
author = John Doe
author_email = john.joe@gmail.com
license = mit

[PyScaffold]
extensions = 
    django
    tox
    travis
    cookiecutter
    namespace
cookiecutter = /path/to/template
namespace = my_namespace.my_sub_namespace

Please notice that if author and author_email are present in the global config, we don't have to use git config --get.

Currently, extension classes have an args property that are being serialized as a string. I believe that, if this property is a dictionary, we can create a new subsection. This would allow us to do something like:

[metadata]
# ...

[PyScaffold]
# ....

[PyScaffold:update]
strategy = keep
except =
   setup.py
   tests/conftest.py

(Related to #138)

@abravalheri abravalheri added the enhancement New feature or request label Jul 15, 2019
@FlorianWilhelm
Copy link
Member

I like this feature and it can be quite easily added, right? Even as an extension maybe, that would be great. Then we could see how many people use it and it would be less invasive.

abravalheri added a commit that referenced this issue Jul 18, 2019
This function contains parts of the old `process_opts` (cli)
that were moved to `get_default_options` in a failed attempt.

Additionally a more generic way of reading config files is implemented
to facilitate #236
abravalheri added a commit that referenced this issue Jul 18, 2019
Reformulate how project path and package name work together

The changes include:
- Removing the `project` parameter and adding `name` and `project_path`
- Changes in the definition of the project structure (the dictionary now represents the entries bellow `project_path` and does not include it).
- Internalize some of the `cli.process_opts` to `create_project` so the Python API can take advantage of it when not running from the cli.
- Removal of deprecated code
- Better integration with `pathlib`
- `create_project` can now read some extra config files (`opts["config_files"]`) in addition to project's own `setup.cfg`  (if updating). This helps future implementations like the ones proposed in #236.

Closes #219 
Missing tests to check if #138 is also solved.
abravalheri added a commit to abravalheri/pyscaffold that referenced this issue Jul 9, 2020
As discussed in pyscaffold#236, this commit introduces the ability of storing your
"favourite" configuration for PyScaffold in a config file in the user's
home directory:

- OSX: ~/Library/Preferences/pyscaffold/default.cfg (or something like that)
- Windows: C:\Users\<username>\AppData\Local\pyscaffold\pyscaffold\default.cfg
- Linux/Others: $XDG_CONFIG_HOME/pyscaffold/default.cfg with fallback to ~/.config/pyscaffold/default.cfg

In order to provide these nice and compliant defaults, this commit
introduces a new vendorised package (`appdirs`) inside pyscaffold.contrib.
This is done to avoid adding dependencies to PyScaffold itself.
The `appdirs` module is very small and MIT-licensed, but rewriting its
features would be painful and require lots of efforts, specially for
testing. I assume that this feature is highly valuable for PyScaffold's
users (it gets really tedious after a while to type the same extensions
all the time), and therefore it is worthy.

There is an on going discussion about simplifying PyScaffold to not be
required in build time and therefore eliminating the needs for
vendorising dependencies. With the current written code, that is very
easy to change.

Future works not included in this PR:
- Add a `--config` flag to the CLI to specify passing a different config
  file/ `NO_CONFIG`.

Closes pyscaffold#236.
abravalheri added a commit to abravalheri/pyscaffold that referenced this issue Jul 9, 2020
As discussed in pyscaffold#236, this commit introduces the ability of storing your
"favourite" configuration for PyScaffold in a config file in the user's
home directory:

- OSX: ~/Library/Preferences/pyscaffold/default.cfg (or something like that)
- Windows: C:\Users\<username>\AppData\Local\pyscaffold\pyscaffold\default.cfg
- Linux/Others: $XDG_CONFIG_HOME/pyscaffold/default.cfg with fallback to ~/.config/pyscaffold/default.cfg

In order to provide these nice and compliant defaults, this commit
introduces a new vendorised package (`appdirs`) inside pyscaffold.contrib.
This is done to avoid adding dependencies to PyScaffold itself.
The `appdirs` module is very small and MIT-licensed, but rewriting its
features would be painful and require lots of efforts, specially for
testing. I assume that this feature is highly valuable for PyScaffold's
users (it gets really tedious after a while to type the same extensions
all the time), and therefore it is worthy.

There is an on going discussion about simplifying PyScaffold to not be
required in build time and therefore eliminating the needs for
vendorising dependencies. With the current written code, that is very
easy to change.

Future works not included in this PR:
- Add a `--config` flag to the CLI to specify passing a different config
  file/ `NO_CONFIG`.

Closes pyscaffold#236.
abravalheri added a commit to abravalheri/pyscaffold that referenced this issue Jul 13, 2020
As discussed in pyscaffold#236, this commit introduces the ability of storing your
"favourite" configuration for PyScaffold in a config file in the user's
home directory:

- OSX: ~/Library/Preferences/pyscaffold/default.cfg (or something like that)
- Windows: C:\Users\<username>\AppData\Local\pyscaffold\pyscaffold\default.cfg
- Linux/Others: $XDG_CONFIG_HOME/pyscaffold/default.cfg with fallback to ~/.config/pyscaffold/default.cfg

In order to provide these nice and compliant defaults, this commit
introduces a new vendorised package (`appdirs`) inside pyscaffold.contrib.
This is done to avoid adding dependencies to PyScaffold itself.
The `appdirs` module is very small and MIT-licensed, but rewriting its
features would be painful and require lots of efforts, specially for
testing. I assume that this feature is highly valuable for PyScaffold's
users (it gets really tedious after a while to type the same extensions
all the time), and therefore it is worthy.

There is an on going discussion about simplifying PyScaffold to not be
required in build time and therefore eliminating the needs for
vendorising dependencies. With the current written code, that is very
easy to change.

Future works not included in this PR:
- Add a `--config` flag to the CLI to specify passing a different config
  file/ `NO_CONFIG`.

Closes pyscaffold#236.
abravalheri added a commit that referenced this issue Jul 15, 2020
As discussed in #236, this commit introduces the ability of storing your
"favourite" configuration for PyScaffold in a config file in the user's
home directory:

- OSX: ~/Library/Preferences/pyscaffold/default.cfg (or something like that)
- Windows: C:\Users\<username>\AppData\Local\pyscaffold\pyscaffold\default.cfg
- Linux/Others: $XDG_CONFIG_HOME/pyscaffold/default.cfg with fallback to ~/.config/pyscaffold/default.cfg

In order to provide these nice and compliant defaults, this commit
introduces a new vendorised package (`appdirs`) inside pyscaffold.contrib.
This is done to avoid adding dependencies to PyScaffold itself.
The `appdirs` module is very small and MIT-licensed, but rewriting its
features would be painful and require lots of efforts, specially for
testing. I assume that this feature is highly valuable for PyScaffold's
users (it gets really tedious after a while to type the same extensions
all the time), and therefore it is worthy.

There is an on going discussion about simplifying PyScaffold to not be
required in build time and therefore eliminating the needs for
vendorising dependencies. With the current written code, that is very
easy to change.

Future works not included in this PR:
- Add a `--config` flag to the CLI to specify passing a different config
  file/ `NO_CONFIG`.

Closes #236.
@abravalheri
Copy link
Collaborator Author

Global config is now added, the only thing left is to at least add an option to specify using no file (custom file location might be added but not strictly necessary)

abravalheri added a commit that referenced this issue Jul 28, 2020
This extension adds CLI opts for manipulating config file and closes #236.
abravalheri added a commit that referenced this issue Jul 28, 2020
This extension adds CLI opts for manipulating config file and closes #236.
@abravalheri
Copy link
Collaborator Author

The missing parts are done in #304

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