synesthesia-it / murray Goto Github PK

It would be great to have a custom plugin that executes shell commands before or after each bone phase

Murray should support installation through brew

To allow Murray functionalities to be included in third party software

To avoid name conflicts when more than a Bones reporitory is being used, Murray should be able to use namespaces.
Example: Bonespec Foo has a model bone, and also Bonespec Bar.
Users should be able to use something like murray bone new Foo.model MyModel or murray bone new Bar.model AnotherModel

Errors should have a readable and understandable description and should cover all cases.

install swift from swiftenv
-https://gist.github.com/Azoy/8c47629fa160878cf359bf7380aaaaf9
-list swift version: https://swift.org/download/#releases
clone murray https://github.com/synesthesia-it/Murray/tree/develop
cd Murray
swift build -c release
copy .build/x86_64-unknow-linux/releas /opt/
alias murray='/opt/Murray/murray'

ERROR
Build error: missingLinuxMain
-create empty file named “LinuxMain.swift”
libdispatch error
-sudo apt-get install libdispatch-dev

As of today, using custom parameters in murray bone new command in quite complex:
the default parameter is used for the name placeholder in templates, but using other placeholders requires something like

murray bone new testProcedure MyTest --param "module:MyCustomModuleName" --param "someOtherKey:somethingElse"

It would be much better to support something like

murray bone new testProcedure MyTest --module "MyCustomModuleName" --someOtherKey "SomethingElse"

We should explore Commander and see if such parameters are supported or find a more viable (and usable) solution

Proper test cases should be implemented in order to futureproof the whole project

Murray's core should accept external, custom-made plugins that can interact with files and project structure. One example could a xcodeproj based plugin that, when installed and when specifically required by bones, can alter the .xcodeproj structure in proper ways.

Code should be linted automatically, if possible.

all commands should have a --verbose flag to enable proper logging

Skeletons should be able to include some "resolving logic" in its very own files.
While it's true that, in some cases, the original project may not work properly or compile when containing Stencil placeholders, however this may not be a concern for a Murray user.
Example use cases:

• resolve Project Name in Readme.md
• resolve a .podspec file

in some development cases, it would be easier to "checkout" a local copy of skeleton without having to continuously commit/pushing it on a remote server

In some contexts, it could come in handy to have recursive resolution of strings against current context, where context is a mix of local values (example: the name parameter from shell command) and environment values in Murrayfile.json.

Environment values may contain other placeholders and used as "variables" when lots of templates are created.

Use case:
MurrayFile:

"environment": {
  "myCustomPath": "innerFolder/{{name|firstUppercase}}/{{name}}"
}

and BoneFile:

{
"to": "{{myCustomPath}}.swift"
}

Possible Approach:

A string should be recursively re-resolved only when Stencil instruction are contained within. However, the quickest approach is to call resolve again on a just-resolved string if its contents have changed after resolution.
In other words, we could have a pseudo method like this:

extension String {
 func resolve(against context: Context) {
 let resolved = self.properResolution(context: context) //the already existing method
    if resolved == self {
       return self
     } else {
        return resolved.resolve(against: context)
     }
}
}

Something to checkout:
in a BoneItem.json, this syntax seems broken

...

"plugins": {
"xcode": { "targets": ["{{someVariableFromMurrayfileEnvironment}}"]
}

Check out if string resolution against context is properly setup

Plugins features have been included in Murray. This means that anyone can build a dylib plugin extending base Plugin class, copy in ~/.murray/Plugins folder and have it working at runtime.

In order to have an external plugin, a swift package with a dynamic library target needs to be created and linked to MurrayKit. This is technically working, but leads to duplicate links at runtime, since both CustomPlugin and Murray are linking to MurrayKit.

I believe there's some issue with SPM and I'd like to retry with final version of Swift5 and see if those warnings goes away. In the meantime, I'd like to keep the XCodePlugin inside MurrayKit and externalize it in the future in a separate repository.

Let's use wiki pages for specific documentation, leaving the only Readme.md as Murray's main description.

Proper versioning system should be designed and implemented on Murray and templates (bones and skeletons). We should aim to backward compatibility whenever possible from 1.0 onwards.

_{Sent with GitHawk}

As of today, Plugins defines custom implementations to be run before or after each item/procedure resolution.

This gives Murray developers a great control over how they implement each plugin, but lacks of control for Murray users when they want to use plugin details with some kind of context over current element being processed.

Lets take the Shell plugin used in an "after item replacement" phase.
it's easy to add a command like echo Hello after each replacement, but what if a user wants to echo current Item destination path or something similar?

Murray Plugins should inject in provided context some special variable like _inputPath or _outputPath with current input properties, so that the plugin section of a BoneItem can contain something like echo {{_inputPath}}, with complete control over shell commands configurations.

• custom names should all start with a _, so that it's harder to collide with provided context
• in any case a custom name should overwrite a previously existing property inside provided context
• context override should shared between every plugin (future-proof), maybe in the Plugin base-class.

List of possible values:

• _name: name of current item / procedure being processed
• _sourcePath: complete path of source template
• _destinationPath: complete path of destination template

At the moment, when a new bone is created, each file in the bone are first copied to final folder (with original template name and not resolved name) and only then resolved with placeholder contents and finally renamed to final filename.
This leads to improper error handling: user gets the error ("a file already exists") but leaves the original bone template in final folder, preventing future executions of similar bones with same data.

Proper usecase should be

1. check if resolved name exists in final folder. If exists, error out
2. copy template contents in memory, resolve its contents and save it to final folder. If any error happens, final folder is untouched.

Custom filter will be named snakeCase
ex:
{{ name | snakeCase }}

I've tried to setup murray on an already existing project, and after cloning the Bones repo, murray fails to find the bone:

murray bone new pipe carrier
Folder at /Users/Oni_01/Documents/JOBS/Personal/DIPathFinder/.murray//Bones/Sources/Bones has no subfolders 

IDK if the problem is related to the Skeletonspec.json or the Bone definition in my repo...

Murray should be able to look for comment/text placeholders in other files and replace those contents with custom contents.

Placeholder should be restored after replace

When creating a new bone with murray bone new using an Item containing nested folders instead of plain files (like this one), folders are getting duplicated.
Example:
Source folder structure : fastlane/actions/somefile
Expected outcome : fastlane/actions/somefile
Actual outcome: fastlane/actions/fastlane/somefile

otherFileRules is proving itself a lot more useful than originally expected, expecially with XML files.
It would be useful to load a template string from an external file in addition to the simple text field in JSON

Murray should provide proper documentation and clearify its main goal and features

XCode plugin (temporarily integrated inside Murray bundled plugins) doesn't work if no folder is found in ~/.murray/Plugins.

When an invalid JSON is provided (either Murrayfile / BonePackage / BoneItem .json), the returned error message is completely useless (something like error - missing).

On ios projects created from Skeleton, sometimes murray stays stuck on pod install.
Pods are actually created and installed, but user has to force-quit (ctrl-c) the murray process to proceed

We should support Carthage, Cocoapods and SPM

It would be cool if you can choose if url is absolute or relative

As of today, plugins are set to be run individually after each BoneItem execution.

With the implementation of the shell command plugin described in (#37 ), it could be useful to have commands (and possibly every plugin action) to be run once after every procedure.

A common use case scenario could be the complete project clean/regeneration to be run only after every item in the procedure has finished running, (or only before the first one), rather than duplicating the same plugin execution N times when is not needed.

In order to do so:

• new PluginPhase needs to be defined (I'd say beforeProcedure and afterProcedure
• those new phases must be executed in proper phases during the procedure pipeline
• Xcode plugin and Shell plugins must be updated accordingly

It could be really useful to choose between JSON and YAML for configuration files.
YAML and JSON can be converted to [String: Any] and used independently.

We should try to implement it without breaking current structure, I suggest:

• in links to Murrayfiles, Packages, ecc..., proper parser (JSON or YAML) is derived by file extension
• if file extension is not present, we try to decode with JSON and if fails, with YAML.

Experienced on a "fresh" machine that never cloned with terminal from Gitlab:

• murray bone setup for bones on private Gitlab repo through https
• Username is prompted
• Password is never prompted.

temporary Workaround:

• one-time git clone https://gitlab.com/.... to any folder, so that credentials are asked
• insert credentials when prompted. Git credentials are stored locally
• retry murray bone setup

A Makefile should be used in order to automate project setup and tests.

Murray CLI does not support a version command to read current version.

We should investigate for a way to automatically detect the version (maybe from tag?) and include it in a local file.

We can use XCodeProj to integrate the XCodePlugin instead of the currently implemented ruby script

Add documentation for MurrayKit so it can be included in other Swift tools

We should have the same behavior we already have on skeleton creation: after proper bone creation, developer may need to launch custom scripts.

When using different packages, it's not possible to have the same procedure name in each one of them.

Example:

• Package1 has a procedure named test
• Package2 has a procedure named test

murray list output:

Package1.test
Package2.test

murray run Package2.test Something returns an error
murray run test Something always executes the first in the list

Currently, all bones creates files according to input name variable.
We should handle the case where some bones force lowercase/uppercase

Bonespec serialization needs to be checked: we're currently losing all custom plugin data.

Murray ~> 2.0 is pretty stable and proven itself a useful tool for quick project bootstrap.

I'd like to reboot the whole project since it suffers from two main issues:

• Tests are far from simple to maintain and extend. Quick and Nimble are apparentely less and less used (way less than I originally imagined) and XCTest alone is powerful enough. Besides that, SPM finally introduced support for resource bundles, meaning that we can mock Murray scenarios (folders with files and demo projects) way more easily.
• Configuration is sometimes a hassle, mainly because I chose JSON as default config "language". YAML is way more powerful (as I've learned from XcodeGen :) ). It seems legit to move to YML as default, while retaining compatibility with JSON.
• CLI may be improved, with more commands and explanations
• Logs and error message are poor and not self-explaining. I'd love to rethink the whole CLI experience with colors and something that it's easy to read

3.0 reboot will follow same approach as 2.0 regarding file structure and naming, and will (try to) not have breaking changes.

Bonefiles are basically useless, since they simply represents an array of remote repositories to include in current project.

We should add a property to skeletonspec representing the array of remote files.

https://github.com/stencilproject/Stencil