Parking lot

[ehmatthes]

This is a holding place for issues that arise in working toward 1.0, but aren't worth a separate issue that will likely become stale for a while. If you want to work on one of these tasks, feel free to open a new issue dedicated to that task. I want to avoid having a large number of small issues open, making the project look less maintained than it is.

[ehmatthes]

• [ ] When running Platform.sh e2e tests, if the CLI is not authenticated the test hangs on the first run. A subsequent run catches the not authenticated error message. Not obvious to troubleshoot quickly, because it's only some runs that hang. Problem likely in platform_sh/tests/e2e_tests/utils.py:

  def check_logged_in():
  """Check that user is currently logged in to Platform.sh through CLI."""
  print("\nVerifying logged in to Platform.sh CLI...")
  auth_info_output = make_sp_call("platform auth:info --quiet", capture_output=True)
  if "LoginRequiredException" in auth_info_output.stderr.decode():
      msg = "\n----- Error: Not logged in through CLI -----"
      msg += "\nPlease log in to the Platform.sh CLI and then run the e2e test."
      msg += "\n  You can log in with the command: platform login"
      msg += "\n-----\n"
      print(msg)
  
      exit_msg = "Please run `platform login` and then run e2e tests."
      pytest.exit(exit_msg)

• [ ] Ensure each platform's CLI is updated before running e2e tests? Many failures seem to come from the CLI being updated automatically during the test run, which interferes with the automated deployment/testing process.

[ehmatthes]

Tasks related to supporting plugins

• [x] Separate private utils from public utils. Public utils are utils that are meant to be used by plugins. See #340.
  • [x] Consider utils/sd_utils.py and utils/plugin_utils.py.
• [x] Separate functions from methods? Or can functions simply accept sd object?
  • [x] If functions accept sd object, consider mocking sd object for testing purposes.
• [x] utils.add_file() should validate that either contents is provided, or template and context are provided. Not all three.
  • [x] Or, contents should be rendered by calling function, and this function only takes contents?
• [ ] See unfinished tasks in #319.

[ehmatthes]

Simplifying plugin_utils

I don't really like how many of the plugin_utils functions require the sd_command argument. It's boilerplate, and not entirely clear. I'm accepting it for now because I like plugin utility functions much better than a set of methods on Command that the plugin needs to call. I think it's better for plugin authors to read through a single module of functions they can use, than to have to look into the simple_deploy.py listing with all its internals.

• [x] Make a plugin_utils.init() function that register required resources such as sd_command.stdout as a global. This is not ideal, with all the issues that globals bring about.
• [x] Create a config module or object containing the elements of state that need to be shared, and pass that around instead of a reference to the command itself. (This seems most appealing!)

[ehmatthes]

• [ ] Support consistent approaches across all platforms, such as confirming before overwriting.
  • [ ] Consider an "all" response, if would like permission to overwrite all files found.
  • [ ] Make sure approach to selecting from multiple resources such as orgs and project names is consistent.
  • [ ] Consider posting a template repo that can be forked or copied, for building new plugins.

[ehmatthes]

• [ ] In plugin_utils.modify_settings_file(), consider just accepting a string for the modified block. The template would be part of core, since it's the same across platforms?
  • [ ] This really depends on how likely it is for platform-specific templates to have unique entries in the context dict. Fly passes one, but it isn't used in the template. How likely are platforms to want this?
  • [ ] If so, plugins can call plugin_utils.get_template_string() for this (or any file!).
  • [ ] Final reason for not implementing this now (#354): it's rather helpful to see a template that looks like an actual settings.py file when considering how to modify settings. The templates as they are have the same indentation structure as a modified settings.py file.
• [ ] Make a nicer CLI, like this?
• [ ] Refine error message raised if plugin not found. Account for typos, maybe list default plugins, suggest installing a plugin? See sd_utils._get_plugin_name_from_packages(). Can also parse available packages starting with dsd-.
• [ ] Make a central list of officially supported (default) plugins in one place, and make sure that list is no longer hard-coded anywhere, ie in platform/ plugin validation work.
• [ ] See unfinished tasks in #362, as plugins become refined. Specifically, handling of testing for contributors who don't have development versions of all default plugins installed.
• [ ] Write a script to clone all four repositories to a folder you specify? A bootstrapping script for contributing to this project? That way a contributor could clone all repos to a single dsd_work dir?
• [ ] In e2e tests, make import paths more unique? Right now, they're e2e_tests.test_deployment and e2e_tests.utils, which could overlap with core.

[ehmatthes]

Supporting non-default plugins

• [ ] Root conftest.py should look for all installed plugins, and discover their tests.

• [ ] If there's any issue with plugin test collection because modifying config.args is bad, go back to hard-coding default plugins in pytest.ini:

  [pytest]
  # This assumes that the default plugins exist in the same directory as django-simple-deploy.
  testpaths = 
  
  # Core simple_deploy tests.
  tests
  
  # Tests for default plugins.
  ../dsd-flyio/tests/
  ../dsd-platformsh/tests/
  ../dsd-heroku/tests/