Looking for opinions on a library management script

[VxE]

One of my side projects is a script that (and this is the bare bones requirement) installs and uninstalls files in the AHK library folders. Naturally, only libraries that include a certain configuration file would be considered 'actionable' by this script. In no case would the script attempt to interfere with non-participating libraries.

What I'm unsure about what the best scope is for the project. I've narrowed it down to two general levels: at the most basic level, the script would be included with each library (should the author be so inclined) package and would allow the user install, uninstall, and (maybe) update that one library using a rudimentary gui.

The more fully featured plan would produce an entire application that would keep track of all libraries, whether they are installed or not, their version, license, and dependencies. An intuitive gui would allow the user to perform relevant actions on participating libraries (other libraries would be "read only" to the script).

Would you use such a script (as either a user or library author)? Are there features or functionality you consider important for a project like this? Have other thoughts?

[tank]

as soon as i can find the time or one of those with access finds time. there is a PHPBB mod that makes any code submission go into a repository
it sounds like it might be a simple thing to also add in a feature to give your script a way to capture current script versions filter by user forum etc
this would give us a way to say copy certain threads to a "library forum" and become an Official Library of sorts. when the owner edits a script it automatically updates the repository


thoughts?

[VxE]

Thanks for the feedback! It sounds like you would support a one-stop-shop for AHK libraries? Such an enterprise level solution is very ambitious at this stage of the project.

I want library authors to freely choose whether to abstain, participate, or change their minds, so I wouldn't want to have automatic repositories. Also, I'd prefer not to use the forum as a database for this project.

I guess I should explain how the script knows what a "library" is. The script looks for a package manifest (the "certain configuration file" I mentioned) which provides the details of the package and its contents. The manifest could identify source files in a number of ways, including relative filepath and URL. The script might keep a copy of each manifest, thereby allowing safe and easy management of those packages.

I imagine a user of this script would only need to download a package manifest file and click "Install" in the script's gui, then the script would take care of downloading the library source files and putting them in the user lib folder.

If this project is successful enough to warrant a central database, the database could store the package manifests (using a proper data model) and support an API for searching and downloading them.

[TLM]

This sounds like a wonderful idea guys. A great way to rebuild and maintain script libraries too.

[joedf]

LibCon!

[MasterFocus]

I support this idea and would probably like to participate, but I already mantain my code at GitHub.
So, would I just link my code there?

[VxE]

I have a tentative name for the project: Script Library Install Manager (SLIM for short).

@MasterFocus: that is correct. If your source is on GitHub and you wanted to release a specific version of your project, your package manifest would specify a URL like "https://github.com/<user>/<project>/<co ... /<filename>" as the source for a file in your release package (source is a member of each file data object in the manifest). When SLIM installs the package, it downloads any files that have a URL as the source.

I'm glad to hear such enthusiasm for the project! When I start rolling out usable versions, I'll also release package manifests for some of my function libraries so everyone can see how they're structured. I doubt that I'll maintain a public schema for the manifests as I expect to update SLIM's capabilities regularly.

[PointCloud]

I +1 this idea. I posted something on the first or second day about lib's. This would help solve the number one problem. Which is organization and accessibility. Also if the ability to check for updates or be notified of updates would be awesome. This would be a asset to community. The less confusion the better.

Cheers!

[budRich]

Excellent idea, keep up the good work.

[DataLife]

This is one of the best ideas in a long time.

Knowing the dependencies is very much needed.

When I first started with ahk I would download and run a script and see I didn't have a particular library, I would search and download that one and run the script again and see I needed another one.

Each time a new user asks a question in "Ask for Help" about what this "Call to nonexistent function" error means they could be pointed to the SLIM thread.

[hoppfrosch]

Your specs sounds similar to a web based AHK-Library management system developed by maul.esel: libba.net. I'm not sure what's the current state and whether it's developed anymore ...

[VxE]

Thanks hoppfrosch, that libba project does indeed overlap some of SLIM's planned functionality. It looks like maul.esel was going for a centralized database of AHK libraries. At this stage, I'm focusing on the client-side.

What I have so far is an outline of the core functional requirements and a prototype for the manifest file format. A manifest file should contain all the information you would want displayed in the SLIM gui (e.g: library name, author, version, license, list off files, etc...).

This is only a prototype, so it is going to be expanded, but it should serve to illustrate some of the things I want SLIM to do, such as multi-language support, 'bundling' packages into one manifest, and varying the location of actual library code. I'm still working on the part that tells SLIM which files to install and how to install them.

Code: Select all

{	"MANIFEST":
	{	"PACKAGES":
		[
			{	"Name":"AHK-Lib-Table"
			,	"Author":"VxE"
			,	"Version":"1.00"
			,	"Category":"AHK Library"
			,	"UpdateFrom":"%Package.files.manifest.slim"
			,	"Info":
				[
					{	"Language":"EN-US"
					,	"Title":"Table (TSV) Manipulation Library"
					,	"Pitch":"This library offers a collection of functions for working with tabular data as delimited (tab separated value) strings."
					,	"Description":"(none)"
					,	"License":"Copyright \u00a9 2011-2013 VxE. All rights reserved.\n\nRedistribution and use in source and binary forms, with or without modification, in whole or in part, are permitted provided that the following condition is met:\n\n1. Redistributions must retain the above copyright notice, this list of conditions and the following disclaimer.\n\nTHIS SOFTWARE IS PROVIDED BY VxE \"AS IS\" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL VxE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE."
					}
				]
			,	"Requires":[]
			,	"Files":
				{
					"README.txt":{"Source":".\\"}
				,	"LICENSE.txt":{"Source":"%Package.License"}
				,	"MANIFEST.slim":{"Source":".\\"}
				,	"Table_Aggregate.ahk":{"Source":".\\"}
				,	"Table_Append.ahk":{"Source":".\\"}
				}
			}
		]
	}
}

[hoppfrosch]

Thanks hoppfrosch, that libba project does indeed overlap some of SLIM's planned functionality. It looks like maul.esel was going for a centralized database of AHK libraries. At this stage, I'm focusing on the client-side.

I think maul.esel also works/worked on the client side - it's the part called "marmoreal" (as far as I remember). I'll try to get in touch with maul.esel and get an update of the current state of libba ... (haven't seen him active on AHK forums for a longer time ....)

EDIT: There's also a trello-board for libba, where some of the specs had been discussed

[hoppfrosch]

I've got response from maul.esel - he has abandoned AHK/Windows in favour of ubuntu. Therefore libba is a /another) dead horse yet. Nevertheless a lot of concepts/questions have been already discussed in context of liba (versioning of library? central hosting? library documentation standards ...) which might be worth to look at and maybe considered within this development

[VxE]

Amazing! thanks again, hoppfrosch. I just scanned the libba trello board and it looks like SLIM is its spiritual successor.

I have solutions for most of the questions discussed there that also apply to SLIM (e.g: versioning management, caching & local DB, version-specific dependencies). Questions about maintaining an official stdlib are outside the scope of SLIM (for now, anyways).