Suggested fix for #70. This allows for the Nautobot module dependency defined in pyproject.toml to be parsed successfully both in its string form and its inline-table form.
If a user wants extras included with the Nautobot dependency, such as "napalm" or "remote_storage", they will appear in pyproject.toml like so:
toml.load will represent this as a dict-like object. We can try to parse it as a dict first, then fall back to parsing it as a string. As far as I know, these should be the only two forms the version value will come in for most use cases. Multiple constraints bring a list-of-dicts form as well, but I'd imagine that's more of a fringe case.
I would also advise considering the possibility of users supplying one of the different possible version strings. For example, if a user wants to add the 'napalm' extra to their Nautobot dependency, they would most likely do so with the poetry add command:
poetry add nautobot[napalm]
Since no version is specified, Poetry defaults to setting the version string to ^(current version), i.e. ^2.2.2. That caret is going to throw a wrench in Docker's rendering of the Nautobot image URL:
The resolution for this comes down to the project's preference. If you want to constrain the dependency versioning to only using a static version, I think raising a warning to the user would suffice. Otherwise, you'd have to tackle the less trivial task of parsing poetry.lock for the resolved Nautobot module version.
Suggested fix for #70. This allows for the Nautobot module dependency defined in
pyproject.tomlto be parsed successfully both in its string form and its inline-table form.If a user wants extras included with the Nautobot dependency, such as "napalm" or "remote_storage", they will appear in
pyproject.tomllike so:toml.loadwill represent this as a dict-like object. We can try to parse it as a dict first, then fall back to parsing it as a string. As far as I know, these should be the only two forms the version value will come in for most use cases. Multiple constraints bring a list-of-dicts form as well, but I'd imagine that's more of a fringe case.I would also advise considering the possibility of users supplying one of the different possible version strings. For example, if a user wants to add the 'napalm' extra to their Nautobot dependency, they would most likely do so with the
poetry addcommand:Since no version is specified, Poetry defaults to setting the version string to
^(current version), i.e.^2.2.2. That caret is going to throw a wrench in Docker's rendering of the Nautobot image URL:https://github.com/nautobot/nautobot-docker-compose/blob/40eec0879a0e8f271eedcaf0f67ade55166ca6b5/environments/Dockerfile#L1-L3
The resolution for this comes down to the project's preference. If you want to constrain the dependency versioning to only using a static version, I think raising a warning to the user would suffice. Otherwise, you'd have to tackle the less trivial task of parsing
poetry.lockfor the resolved Nautobot module version.