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

Update Project to Use Poetry #68

Merged
merged 43 commits into from
Apr 18, 2024
Merged

Update Project to Use Poetry #68

merged 43 commits into from
Apr 18, 2024

Conversation

jdrew82
Copy link
Contributor

@jdrew82 jdrew82 commented Jan 19, 2024

This PR is to refactor the project to use Poetry for dependency management instead of requirements.txt and the older build system. I've made this update to address the following:

  1. Now that we have multiple major versions of Nautobot and Apps we're seeing users experiencing difficulty in managing their dependencies and having unexpected upgrades and changes occurring. Using poetry will enable users to choose their expected Nautobot version and have the most compatible App versions recommended during the dependency resolution process.
  2. The current structure requires utilizing multiple different files for creating the environment and also customizing it. If we change to Poetry this is simplified a lot to executing some shell commands in most cases.
  3. We utilize Poetry and invoke in our Apps and are suggesting it's use in the cookiecutter so should be consistent.
  4. This aligns closer to how we're deploying Nautobot with K8s.

@jdrew82 jdrew82 self-assigned this Jan 19, 2024
@jdrew82 jdrew82 requested a review from jvanderaa as a code owner January 19, 2024 03:48
@jdrew82 jdrew82 marked this pull request as draft January 19, 2024 03:49
@jvanderaa
Copy link
Contributor

What is the part about adding invoke onto this? Are we still able to do docker compose up to get going?

@jdrew82
Copy link
Contributor Author

jdrew82 commented Jan 20, 2024

What is the part about adding invoke onto this? Are we still able to do docker compose up to get going?

I still need to finish updating documentation to include that bit. I think you should still be able to do 'docker compose up' in the environments folder if you specify the project or which files. Need to test to confirm though.

@jdrew82
Copy link
Contributor Author

jdrew82 commented Jan 29, 2024

What is the part about adding invoke onto this? Are we still able to do docker compose up to get going?

I've confirmed that you are able to use docker compose up commands if you want, but you need to add all the additional toggles such as specifying the project name and folder. The invoke command makes this much simpler so I think it makes more sense to just tell users to use the invoke commands.

@jdrew82 jdrew82 marked this pull request as ready for review January 30, 2024 20:51
@sslhansen
Copy link

Just a small comment to the readme. The creds.example.env file is referred to as creds.example.example instead of creds.example.env on line 128 in the code block :)

image

README.md Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved
README.md Outdated Show resolved Hide resolved

```
docker compose -f docker-compose.yml -f docker-compose.mysql.yml up
This repo is designed to provide a custom build of Nautobot to include a set of plugins which can then be used in a development environment or deployed in production. Included in this repo is a skeleton Nautobot plugin which is designed only to provide a quick example of how a plugin could be developed. Plugins should ultimately be built as packages, published to a PyPI style repository and added to the poetry `pyproject.toml` in this repo. The plugin code should be hosted in their own repositories with their own CI pipelines and not included here.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems wrong? We're not going to add any plugins to this repo's pyproject.toml? If the idea is for users to maintain a custom fork with their own set of plugins, that should be made clearer.

(Also, nit - s/plugin/app/g :-) )

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The example plugin was included as there is one in the current version. I think it might be worthwhile to just get rid of it and refer to the cookiecutter-nautobot-app cookies instead. Thoughts? @jvanderaa @glennmatthews

README.md Outdated Show resolved Hide resolved
environments/docker-compose.local.yml Outdated Show resolved Hide resolved
environments/docker-compose.local.yml Outdated Show resolved Hide resolved
Comment on lines 21 to 22
healthcheck:
test: ["CMD", "true"] # Due to layering, disable: true won't work. Instead, change the test

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should probably come up with a good healthcheck like for the nautobot service.

Comment on lines +33 to +34
MYSQL_USER=nautobot
MYSQL_DATABASE=nautobot

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand the logical split between creds.example.env and local.example.env - for example, why is MYSQL_USER in local but MYSQL_PASSWORD in creds?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I considered local.env to be environment variables that are safe to be stored in git vs secrets that shouldn't be saved should go into creds.env.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So a user would fork the repo and commit local.env to their fork? Maybe document that if so.

compose_dir: "environments/"
compose_files:
- "docker-compose.postgres.yml"
- "docker-compose.ldap.yml"

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why does the ldap one not include docker-compose.base.yml?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because the LDAP compose file is identical to base but uses the LDAP Dockerfile. I guess we could just use overrides in this case but was trying to make it easier to understand.

@jvanderaa jvanderaa merged commit 40eec08 into main Apr 18, 2024
2 checks passed
@jdrew82 jdrew82 deleted the feat-update_to_poetry branch April 18, 2024 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants