Pylance is reporting the argument parser is not properly exported from the module, causing it to fail checks.

"ArgumentParser" is not exported from module "pydantic_argparse" Pylance[reportPrivateImportUsage](https://github.com/microsoft/pylance-release/blob/main/DIAGNOSTIC_SEVERITY_RULES.md#diagnostic-severity-rules)

I noticed the package restricts installation to python3.9 exclusively, are there any known compatibility problems with other versions?

Problem

• pydantic-argparse should have a project logo, rather than the current standard # h1 text heading.

Solutions

• Make a logo myself?
• Wait for a contributor to make a logo?
• Pay someone to make a logo?

Problem

• pydantic-argparse currently has a container type argument field parser.
• However, more generically it should be called a sequence parser.

Solution

• Instead of a container parser, it should be renamed to a generic sequence parser.

Problem

• Investigate Python Github action built-in caching
• See: https://github.com/actions/setup-python#caching-packages-dependencies

Solution

• Implement the builtin caching if applicable

Problem

• pydantic-argparse should investigate the benefits and drawbacks of committing the poetry.lock file to version control.
• pydantic-argparse is a library rather than an application.
• See: https://python-poetry.org/docs/basic-usage/#commit-your-poetrylock-file-to-version-control.

Solution

• Remove poetry.lock file from version control if deemed applicable.

Summary

• As raised by @ericchansen in #34, pydantic-argparse should be able to piggy-back off pydantic and support loading environment variables from .env files.
• This can probably be accomplished by defining arguments as shown below:

  class Args(pydantic.BaseSettings):
      my_arg: int = pydantic.Field(description="this is an int")
  
      class Config:
          env_file = ".env"
          env_file_encoding = "utf-8"

• See: https://docs.pydantic.dev/latest/usage/settings/#dotenv-env-support
• If this does work, it might be nice to provide a dotenv extra for pydantic-argparse (similar to pydantic) so people can install it with:

  $ pip install pydantic-argparse[dotenv]

Summary

• As raised by @lucidfrontier45 in #48, we need Pydantic v2 support in pydantic-argparse.
• We now have pseudo-Pydantic v2 support, as the pydantic dependency is at least unpinned.
  • See: #55
  • See: v0.9.0
• However this is just a shim to the Pydantic v1 API.
• We should implement real Pydantic v2 support.
• I think maintaining both Pydantic v1 and v2 compatibility is probably unreasonable (TBD).
• More information to follow...

Notes

• Looks like our forks may have done some of the heavy-lifting
  • See: https://github.com/cody-mar10/pydantic-argparse
  • See: https://github.com/alejoe91/pydantic-argparse/tree/pydantic2

Problem

• pydantic-argparse should investigate the usage of flake8, to find what it can provide that pylint cannot.
• pydantic-argparse should investigate the usage of flake8 plugins such as:
  • flake8-buitins
  • flake8-bandit
  • flake8-docstrings
  • flake8-use-fstring
  • flake8-logging-format

Solution

• Implement flake8 and plugins if deemed appropriate and useful.

Hi great project! I was wondering if it is possible to implement something similar to the argparse packages metavar argument. I strongly prefer my arguments to specify what type should be input, and I would think this is doable since the pydantic backend is already keeping track of types.

Envision something like this:

from pydantic import BaseModel, Field, FilePath

class Args
    intarg: int = Field(..., description="an integer")
    file: FilePath = Field(..., description="a file")

then at cli:

./example_program.py --help

--intarg INT:    an integer
--file FilePath: a file

We need to know if a particular argument has been explicitly set by the user, or it is just the default value.
pydantic provides model.__fields_set__ to check for those, however pydantic-argparsecurrently sets all values, regardless of the user input.

A way of doing this is by not setting defaults in argparse and leave pydantic processing those instead.

I've modified the code in my fork, and I would be happy to contribute a PR.

Thanks.

Problem

• Coveralls badge appears to be broken due to missing redirect in badges/shields#8584
• Looks like it will be fixed in: badges/shields#8644
• Keeping this open to track the above issue

Problem

• A very useful feature of Python's argparse module is adding subparser commands.
• pydantic-argparse currently does not offer this feature in a complete and/or typed way.
• It is highly desirable for pydantic-argparse to implement all of the features of Python's argparse module.
• Therefore, pydantic-argparse should implement this feature before an initial stable release.

Solution

• Subparser commands should be implemented in pydantic-argparse as nested optional pydantic models.
• For example:

  class Command1(pydantic.BaseModel):
      # Command 1 Arguments
      flag_a: bool = False
  
  class Command2(pydantic.BaseModel):
      # Command 2 Arguments
      flag_b: bool = False
  
  class Arguments(pydantic.BaseModel):
      # Global Arguments
      global_flag: bool = False
  
      # Sub-Commands
      command_1: Optional[Command1] = None
      command_2: Optional[Command2] = None

• The case shown above would parse $ app --global-flag command_2 --flag-b as:

   Arguments(global_flag=True, command_1=None, command_2=Command2(flag_b=True))

• This functionality should be recursive, and should work correctly for any n levels deep.

Problem

• pydantic-argparse currently has a json type argument field parser.
• However, it actually just parses regular python dicts using the ast literal eval.

Solution

• Instead of a json parser, there should be a generic mapping parser.

Problem

• It is critical that pydantic-argparse has 100% unit test coverage before an initial stable release.

Solution

• Implement full unit test coverage before the initial stable release.

Hello! Firstly, thank you for this package. I really like it and I want to use it in a project I'm developing.

The project I work on has the minimal Python version of 3.7 (currently the lowest supported version), but your package uses the version 3.9. Hence, my question: would you consider “downgrading” your project to also support Python 3.7 and 3.8? I understand, that you may not want to do this, and it's fine! I could do all the work myself. If you do not want to maintain older Python version at all, it's fine too: I would then fork it and do it on my end. Thanks!

Is there currently a way to allow an argument to be passed positionally? E.g.,

class Args(BaseModel):
    x: str = pydantic.Field(description='The x.', positional=True)
    y: int = pydantic.Field(description='The y.')

./foo.py hello --y 5

Problem

• pydantic-argparse must have full documentation coverage before the stable release.
• This documentation must include working examples and a quick-start guide.
• This documentation must be hosted online, and easily accessible and readable for users.

Solution

• There exist multiple competitors in the hosted Python documentation space:
  • mkdocs
  • sphinx
  • readthedocs
• The options should be evaluated, and the chosen one implemented and hosted online.

Is it possible to generate subcommands in some way?

class BenchmarkArguments(BaseModel):
    type: Literal["benchmark"]
    benchmark: str


class AnalyzeArguments(BaseModel):
    type: Literal["analyze"]
    analyze: str


class Command(BaseModel):
    command: Union[AnalyzeArguments, BenchmarkArguments] = Field(..., discriminator="type")

parser = ArgumentParser(
    model=Command,
    description="arguments",
)
benchmark: Command = parser.parse_typed_args()

Problem

• pydantic-argparse releases must always completely pass linting, type checking and unit testing.
• pydantic-argparse must also adhere to the Google Python styleguide.
• It is highly desirable that these checks are performed before a release is made.
• These checks must also be performed on all Python versions that pydantic-argparse supports (3.9, 3.10)

Solution

• CI such as GitHub actions should be setup.
• CI should run linting, type checking and unit testing on all appropriate Python versions and OS's

Currently Pydantic version is pinned to v1.

Is is possible to loose this restriction to support Pydantic v2?

For example, I have a class like this.

class SubArgs(pydantic.BaseModel):
    name: str

class Arguments(pydantic.BaseModel):
    a: SubArgs
    b: SubArgs

this will give the following usage hints.
usage: Example Program [-h] [-v] {a,b} ...

a or b is a sub command.

How can I set the value of both a and b at the same time?

It would be nice to have the possibility to define in the pydantic.BaseModel Field definition the possible names for the cli arguments. It would be possible to have both: the short and long versions of the same argument.

example:

class Arguments(pydantic.BaseModel):
    debug: bool = Field (..., description="Shows the debug information", alias="my-custom-debug")

above would give the possibility to specify the argument in the command line as command --my-custom-debug

How to add the short version of the same argument i.e: -d

If support for aliases=('d', 'my-custom-debug') would be added it would be nice as pydantic.Field does support extra arguments
Above would be interpreted to add the additional names to the parsed arguments

The automatic pydantic error messages are not very clear, so it would be nice if the developer could pass a function that produces nicer error messages for simple and plausible errors like forgetting to provide an input file.

I got the following model

Arg(BaseModel):
    f = Field(default=os.environ.get("F"),  description="description of F", required=True)

The field is marked as optional even though I provide him with required option. I know I have to remove the default option but I would like to force it to be required.

Otherwise is there a chance to include a field to read variables from env ?