Skip to content
This repository has been archived by the owner on Aug 10, 2024. It is now read-only.

Latest commit

 

History

History
136 lines (111 loc) · 5.24 KB

THOUGHTS.md

File metadata and controls

136 lines (111 loc) · 5.24 KB
Raw

Thoughts

Just some random thoughts which should be taken with a grant of salt.

Ddt should:

  1. play well with other tools and try to integrate in existing workflows as long as it makes sense i.e. through using vcs hooks to auto commit autogenrated changes.
  2. keep all the autogenerated changes to be commited to the minimum for the currently commited code.
  3. if possible allow the human to edit and test autogenerated code to be commited.
  4. make it hard to do stupid things:
  • Example: use .gitignore to hide generated files to prevent them beeing accidentally commited
  1. Try to enforce best practices, but allow people to customize their workflows as long as it's not completly overkill and a burden.
  2. Should run as much as possible in parallel.
  3. Mark files generated during build / install with a distribution installer as autogenerated so a human reading such a file knows where it's coming from.

Workflows

Project creation

  • make directories
  • generate META6
  • generate README
  • generate a class/module/package
  • generate licensing stuff
  • initialize VCS Repository

Patching installed Distributions

  • You install App-Bar
  • App-Bar depends on Net::Foo::Client, Net::Foo::TLS.
  • You start using App-Bar you notice that you are missing some feature
  • Here you have two scenarios

Perfect World

  • Your distribution manager (i.e: zef or panda)
    • already has the source of App-Bar (because it's part of the dist pkg)
  • You edit the source code of the App-Foo distribution like it would be a locally checked out project in $EDITOR. Your editor should interact with with the distribution by running tests ect.
  • Once you are happy with your changes a new branch is created and your distribution manager starts using this branch for your environment
  • Once you think it's stable you can easily do a PR

Current Situation

  • Stupid Approach

    • Find zef locate App-Bar
    • open in editor
    • hack
    • run manual some tests
    • OUTCOME: Lost at next upgrade or forgotten and never merged with upstream

  • Invalid Approaches

    • Using zef look App-Foo it will drop you in a directory without any version control

  • Sensible Approach

    • get Source-url from zef info App-Foo
    • Hope it's some kind of version control url
    • do vcs clone source-url
    • HACK
    • run zef test, prove, prove6 or whatever is suitable for current case
    • do vcs commit when ready
    • use zef --force install . to deploy when ready
    • fork the github repo (i.e: via hub git fork)
    • make a pr (i.e. via hub git pr)
      • Pr is accepted for the current distribution version
      • Pr needs to be rebased on the current master
      • Not accepted: create an own App::Foo:auth(user):ver(X.Y.Z) which emulates App::Foo:ver(X.Y.Z). Release new Distribution and may the fork be with you!

The Sensible Approach has three phases:

  • get version controlled source code for a unit name so you can comfortably edit it with your $EDITOR
  • hacking / testing
  • deploying and maintaining own set of patches on top of the distribution
  • distributing changes

Adding an executable script to the current distribution

How to handle Meta distributions?

Currently it's a custom(?) in the Perl world to generate different distributions from one source and upload them separately to CPAN. This solves a number of issues:

  1. A huge source code repository which is split in different distributions modules. This allows applications to only pull a minimal set of dependencies.
  2. From same source repository multiple distribution versions could be generated. This helps to maintain multiple API versions.

My current issue with that is it makes it harder for the user to contribute back to the project in a way described in Sensible Aproach because:

  • You need all the source code from which the distribution is generated, which may be not deployed on your system. This might be an issue if you have no network connection at the moment. It enforces the human to fall back to the Stupid Aproach
  • Let's hope the distribution authors thought about adding all the relevant tests to the distribution from the main source repository. This might be not an issue if the distribution is generated with a smart tool.
  • How do you integrate with the currently cripled non cpan infrastructure?
  • How to build the distribution locally and install it with zef?

How to handle different unit versions in the source repository

Issues

  • Should they be packaged as separate minimal distributions? If so how to contribute back to the user?
  • Currently perl6 doesn't provide a way to separate between source code for distribution and project vcs repository.

Current Sollution

Use vcs branch / tag feature

ROAD MAP

  • Refactor generation functions out of Ddt::Distribution
  • Use git-hooks
  • Implement Rule 2 from above

Random Examples

  • A function is add to the code and is commited. The post-commit ddt hook is run, in this example it generates some pod data which needs to be commited. There're two cases to handle:
    1. If a human is present—i.e if running from a tty device—present him witht the posibillity to edit the autogenerated code to be commited.
    2. There is no human supervision so just do what needs to be done