This repository has been archived by the owner on Aug 10, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 4
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
16 changed files
with
834 additions
and
412 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,4 +1,18 @@ | ||
| /blib/ | ||
| /src/*.o | ||
| /src/Makefile | ||
| /resources/*.so | ||
| /resources/*.dylib | ||
| .precomp/ | ||
| # Prove saved state | ||
| .prove | ||
| # Vim swap files | ||
| [._]*.s[a-w][a-z] | ||
| [._]s[a-w][a-z] | ||
| # Vim session | ||
| Session.vim | ||
| # temporary | ||
| .netrwhist | ||
| *~ | ||
| # Vim auto-generated tag files | ||
| tags |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,139 @@ | ||
| # 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 | ||
| 5. Try to enforce best practices, but allow people to customize their workflows | ||
| as long as it's not completly overkill and a burden. | ||
| 6. Should run as match as possible in parallel. | ||
| 7. 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 App 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? You | ||
| need some kind | ||
|
|
||
| - then 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 |
Oops, something went wrong.