Right now global command only works with biddle itself

node biddle global

It should be extended to allow the name of an installed application

biddle global myApplication

Removing an application from the global path must be in the uninstall command and also allowed with the global command and a remove argument like current support for biddle

biddle global myApplication remove
biddle uninstall myApplication

This use of global command with an application should perform a check of the application name against the installed.json to determine if the application name is valid or else throw an error.

Don't allow publication into directories that already contain things as this makes unpublication a problem that could destroy other files.

• location - outputs the absolute path of an installed application
  • input: biddle location prettydiff
  • output: /Users/austincheney/biddle/applications/prettydiff/
• origin - outputs the absolute publication point of an installed application
  • input: biddle origin prettydiff
  • output: http://prettydiff.com/downloads/prettydiff/prettydiff_latest.zip

Add a command named version to simply output the value of version from biddle's package.json file.

biddle version

should return:

0.1.15

My posix scripting skills are weak. I will take any help I can get.

Run remote automation builds on Windows servers.

This needs an audit and more in-depth test automation:

• verify version is removed from filedata.json
• verify value of latest is updated
  • verify latest.txt is updated with new value
  • verify published.json is updated with new latest value
• specify latest version on index.xhtml

Problems:

• #20
• index.html not generated
• publications directory included in zip files
• there are no unit tests for publishing updates

Observations:

• publish.json is updated correctly

When the apps.errout function executes from a test run it can cause the installed.json and package.json files to be emptied. In order for this series of events to occur there must be a broken test generated from the biddle test command.

The problem is intermittent and I have only experienced it on my remote Linux webserver. I cannot produce this problem on Windows or OSX.

The problem is present when attempting to publish Pretty Diff:

biddle publish prettydiff

The problem is evident when prettydiff_latest.zip and prettydiff_2.1.15.zip (latest version number) are different sizes. I will need to create a local Linux partition on my Windows computer to investigate this further. I can work around this by unpublishing and republishing until the problem is no longer present, which eventually works but is still not an acceptable solution. This is further not acceptable because the unpublish command will destroy all prior published versions.

A strange side-effect was observed. When attempting to republish from the same current working directory (CWD) as the original publication the zip command was failing and further attempts to republish failed in the same way until I changed my CWD to a different directory.

This issue has two parts:

1. publish prettydiff using biddle and provide a download location from the website.
2. discover monitoring solutions to determine project health, traffic, and other considerations

IPFS is - https://github.com/ipfs

IPFS is like bittorrent for filesystem fragments with git and hashing builtin. This means the publication task can safely eliminate the need to write and store zip files.

Major changes to biddle

• publish - Publication will work the same up till the point of writing a zip file. Instead a ipfs add -r child command will be issued against the temporary directory created for the variant. The filedata.json file will store the IPFS hash value instead of the local path to a zip file.
• install - Install will issue a ipfs get child command. Since IPFS has version control built in applications can be installed and updated without file clobbering, which solves a major biddle limitation.
• IPFS will become a required dependency just like Node. Biddle will not limit itself to a single form of IPFS so long as the generic commands are available from the system path.
• This major change should not require any changes to biddle's installed.json and published.json files.

Centralized management

• The publication task will still write files to a publication point, namely the latest.txt, index.xhtml, and filedata.json. This will provide a uniform location by which application metadata is stored without centralizing the actual application.

Currently biddle is using git submodules for its two dependencies: jslint and prettydiff. The git submodules should be replaced with biddle.

At this time the owner/maintainer of JSLint is not willing to endorse any project that isn't 100% ES6 conformant. biddle will probably never be 100% strictly ES6 because it needs named functions for maintenance of callbacks opposed to arrow functions where are always anonymous and it uses some old style for loops instead of the array forEach method, because some loops need to be broken as appropriate.

The shortest path to resolution is just to old host a biddle publication of JSLint on my own and periodically update it.

Github released a specification for their markdown - http://spec.commonmark.org/0.27/

I need to verify conformance.

The first step is to pass data into functions opposed to referencing from globally stored properties. The most obvious offender is data,input. As much of this stuff as possible must be confined to the init function at the bottom.

Add support for tables and blockquotes to markdown command

biddle unpublish prettydiff 2.1.15

Allow unpublish by version number so that only a specific version of an application is destroyed instead of the entire application.

Using the Node.js crypto library would allow a single universal approach to hashing that is OS independent.

Create universal references for ANSI formatting and use the references instead of the literals in the code.

Current there is a test command that just supports biddle's test automation.

biddle test

This should be extended to installed applications so that biddle can run validation against installed applications:

biddle test myApplication

This issue would require a new property to the application's package.json file so that biddle knows what the test command(s) is/are. These would have to be executed in Node as a child.spawn so that stdout can stream to the current terminal in real time.

If the schema for package.json, and thus installed.json, these changes would need to be reflected in the documentation.

Currently the install command removes the old application and installs the newer version in that location. This means all saved data and configurations will be lost. This is acceptable for the install command.

The word update suggests something less disruptive. The near term (80%) solution is to unzip the downloaded zip to a temporary location and copy the new files overwriting the old files without removing things.

This is not a 100% solution because applications may supply default configurations which would replace a user's preferences saved into the same named config file. A convention would need to exist to balance the needs of an application's user configs against the needs of an application publisher to disruptively change their configuration API. Ultimately, biddle will need to supply a means to identify such breaking changes that should cause warning and user validation during application updates.

I just fixed a critical flaw that should never have been a flaw in the first place. Additional test units are required:

• publish from a relative path outside the current directory tree
• install via http
• get a zip file, unzip the file, and verify contents

Currently installing biddle looks like

biddle install http://prettydiff.com/downloads/prettydiff/prettydiff_latest.zip

which is far more frustrating than the NPM and Homebrew way

npm install prettydiff

The frustration grows as the length of applications grows. The middle ground is to allow users to retain local application catalogs. Quite simply it can be something as simple as a JSON of name value pairs where the name is the application name and the value is its publication point.

This functionality is already present once an application is installed. The value add from this feature is to ease the burden of initial installation. Situations where this would be beneficial:

• Trading catalogs between people online
• Starting fresh on a new machine
• Providing software list recommendations

On posix copy test fails about 1 time out of 10. It seems the biddle code is correct as this is a shallow wrapper around a child process. I suspect, though not validated, the problem is something between an issued a posix command (as a child process) and a verification that follows to quickly after.

On windows this problem occurs more frequently and is typically experienced from the publish test when running biddle test.

Copy command for posix:

cp -R targetPath destinationPath

Copy command for Windows:

xcopy "targetPath" "desintationPath" /E /Q /G /H /Y /J /I

This enhancement will drastically increase performance and accuracy in the publish command.

With this defect if the project is located at /user/myProject and the project download location is /user/myProject/downloads. Biddle will correctly read the download location as a relative path, but incorrectly associate it relative to the current working directory. If your current directory is /applications/tools/awesometool and you attempted to run biddle publish ../../../user/myProject the files will write to /applications/tools/awesometool/downloads instead of /user/myProject/downloads.