You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
octodns 1.0 will be made up of a core at octodns/octodns and first-party providers in separate repos, e.g. CloudflareProvider in octodns/octodns-cloudflare. This means that at 1.0, you will need to install octodns==1.0 and octodns-cloudflare with pip to successfully use Cloudflare as your DNS provider.
The octodns org has around 14 first-party plugins for providers, so we have 15 versions to consider: one for octodns and one for each of the 14 providers. We can generate 15 flavors: one octodns flavor which contains all of them, and then one for each provider which just includes that one provider. The current approach is to manually manage requirements.txt files. I don't think this is going to work long-term (e.g. updating the octodns core package means updating all 15 requirements.txt files).
I'd propose a single file in the root of the repo which stores the versions for all the components used. We'd automatically copy just the versions we need to the flavor we want. One possibility is to store the versions as requirements.txt in the base of the repo, then filter and copy that file into the relevant flavor. We already copy the Dockerfile into each flavor since it's the same across all the flavors, so we can easily do this. I'd vote using grep or awk to make it as simple as possible.
The text was updated successfully, but these errors were encountered:
octodns 1.0 will be made up of a core at octodns/octodns and first-party providers in separate repos, e.g. CloudflareProvider in octodns/octodns-cloudflare. This means that at 1.0, you will need to install
octodns==1.0
andoctodns-cloudflare
withpip
to successfully use Cloudflare as your DNS provider.The octodns org has around 14 first-party plugins for providers, so we have 15 versions to consider: one for octodns and one for each of the 14 providers. We can generate 15 flavors: one
octodns
flavor which contains all of them, and then one for each provider which just includes that one provider. The current approach is to manually manage requirements.txt files. I don't think this is going to work long-term (e.g. updating the octodns core package means updating all 15 requirements.txt files).I'd propose a single file in the root of the repo which stores the versions for all the components used. We'd automatically copy just the versions we need to the flavor we want. One possibility is to store the versions as requirements.txt in the base of the repo, then filter and copy that file into the relevant flavor. We already copy the Dockerfile into each flavor since it's the same across all the flavors, so we can easily do this. I'd vote using
grep
orawk
to make it as simple as possible.The text was updated successfully, but these errors were encountered: