EDITOR PLUGIN: AgsGet - Version 0.1.0

Started by eri0o, Tue 04/02/2020 01:44:36

Previous topic - Next topic

eri0o

AgsGet  version 0.1.0

For information on how to install, see the AGS Manual on how to install plug-ins.



Warning: Dangerously Experimental! Read below before using!

Get Latest Release AGS.Plugin.AgsGet.dll | GitHub Repository

AgsGet is an Editor Plugin for Managing Script Modules. Click the gif below to see it on video.




Warning: Dangerously Experimental! Read below before using!

This Editor Plug-in has the following limitations:

  • It won't work in your game if you are using Script Folders;
  • There may be a case where it crashes and leaves your game in broken state, requiring manual edit of Game.agf;
  • If you install or remove a script module that has the same name of a script in your game it will delete your script and replace it for the module;
  • If you ever install or uninstall a package, any script module listed in the lockfile will replace any changes you do to them for the ones in the Package Cache.


Available features

Supports installing packages from my AGS Module List. You can also uninstall packages installed through AgsGet interface. If a package depends on other packages, the dependencies will be installed too, on the correct order in the scripts list.

A simplified search is provided too, an empty parameter will return all modules available.

For now, it doesn't care for versions, so if you install a package and a newer version of the package is made available on the package index the module you are using may get overwritten by a new version if the package is updated in your package cache.

This plugin should not save anything on itself on your Game.agf, so you should be able to just load a game you used it in an AGS Editor that doesn't have it.

How it works

AgsGet may create the following files in your game directory.

Code: ags

â"œâ"€â"€ ags_packages_cache/
â",   â"œâ"€â"€ package_index
â",   â"œâ"€â"€ pkg1/
â",   â",   â""â"€â"€ pkg1.scm
â",   â""â"€â"€ pkg2/
â",       â""â"€â"€ pkg2.scm
â",   ...
â", 
â"œâ"€â"€ agsget-lock.json
â"œâ"€â"€ agsget-lock.json.removal
â""â"€â"€ agsget-manifest.json


Let's see the steps involved in installing a package:


  • At first, when loading AgsGet, if no package_index is found, it will create the ags_packages_cache directory, and place it inside the package_index file, which is obtained directly from here: https://ericoporto.github.io/agsModuleList/index/package_index.json .
  • Whenever you install a package, AgsGet reads the agsget-manifest.json to figure out which packages are already installed and recreates it including the new package.
  • If there's any agsget-lock.json.removal, it's deleted, and if there's any agsget-lock.json, it's renamed to agsget-lock.json.removal.
  • Then, it reads this generated agsget-manifest.json and the package_index to figure out if the packages have any dependencies, and order them correctly, using topological sorting, writing the resulting list in agsget-lock.json.
  • It then removes and deletes any script and headers in the project with the same name as a package in the agsget-lock.json.
  • It then will download from https://ericoporto.github.io/agsModuleList any package not on cache that it's listed in the agsget-lock.json.
  • Finally, all packages listed in agsget-lock.json gets imported in the Game.agf project and shows in the editor.

Removing a package will remove the package from agsget-manifest.json, and the agsget-lock.json will be recreated, with the previous lock saved as agsget-lock.json.removal. Packages that are listed on agsget-lock.json.removal, but not on agsget-lock.json get removed.

Where do we go from here

This package manager implementation is created more as a proof of concept that it can be done. It appears that two things are actually the most iminent needs:

- A place to list all Script Modules including their metadata (specially to allow creating modules that depends from other modules).
- A place to store these Script Module that everyone can trust (this is a much harder problem to figure out).

Once the above is properly structured, creating the package manager to work with above is a much minor problem.

I created this Editor plug-in cutting a lot of corners to make it live in the shortest amount of time, the main idea was that people could experiment with it and talk about what they think of this idea, assessing if there's need from the community for a package manager or a central database... It's important to note that this tool is supposed to work along with the forum since packages don't work without communities. Mostly of the ideas in making this package manager were taken from this article from Sam Boyer, which has a presented design inspired by the package manager npm. Additionally, the general design of the package repository is based on early iterations of the vcpkg, see it's ports directory.


Troubleshooting

If you downloaded this plugin from the internet and AGS complained something about policies when loading, the file is locked. You need to right click it, click on properties and then click Unblock, see image below.


Edit: I've since include more modules in the website and index accessible through the plugin, if someone is missing a particular module, just comment on it and I will add it.

Monsieur OUXX

This, with the right set of modules, would make AGS very, very powerful.
 

Crimson Wizard

#2
Quote from: Monsieur OUXX on Tue 04/02/2020 14:08:46
This, with the right set of modules, would make AGS very, very powerful.

This needs a properly maintained database where authors could register and update their modules. Right now the list, links and information is kept by hand, in a personal repository.

Monsieur OUXX

Quote from: Crimson Wizard on Tue 04/02/2020 14:31:09
Quote from: Monsieur OUXX on Tue 04/02/2020 14:08:46
This, with the right set of modules, would make AGS very, very powerful.

This needs a properly maintained database where authors could register and update their modules. Right now the list, links and information is kept by hand, in a personal repository.

Yes, the author told me that it was a pain for him, but how about just storing the modules into github, maybe with an info file coming with each module, acting as a manifest?
 

eri0o

#4
Python PyPi has a simple specification for a package repository: https://www.python.org/dev/peps/pep-0503/

It still needs some autoindex generator if you are using a static host for packages like GitHub Pages. Also, tar.gz is a great format for packaging but can be alien to people that are only Windows users.

If this repository is updated through Pull Request from module authors it can still be updated and rely on authors pushing their updates.

Quote from: Monsieur OUXX on Tue 04/02/2020 15:55:56
maybe with an info file coming with each module, acting as a manifest?

I already do this, see rellax:

Code: json
{
  "id": "rellax",
  "name": "rellax",
  "text": "Rellax while the Camera tracks with cool parallax.",
  "forum": "https://www.adventuregamestudio.co.uk/forums/index.php?topic=57489.0",
  "version": "0.1.3",
  "author": "eri0o"
}


It could have an additional field where it would point to the url on the authors original download on the GitHub Release page. The problem is you need at least maintain an index to point to manifests or something. Deciding what should be in the manifest can be part of this discussion, I had to write one for all modules hosted.

Quote from: Crimson Wizard on Tue 04/02/2020 14:31:09
This needs a properly maintained database where authors could register and update their modules. Right now the list, links and information is kept by hand, in a personal repository.

I could not find any reasonable way to do this, maintaining a database is hard work, as is allowing people to write files in your server. Also there's the price to rent/own such infrastructure. I believe there's a way, I just personally don't know. A important note here is I have very little experience with public facing websites and how to build them.

For public generic binary distribution platforms, I found both NuGET (if people agree to write nuspec files) and bintray (if people agree to write pom files).

I could not quite decipher  Sonatype's Nexus and JFrog's Artifactory, but I believe both allow to host a public repository where people could log in and manage their own packages, just found their docs a bit hard to understand, so not sure if this could be done.

Other idea I had is being able to merge indexes, so people could maintain and share their own index and a developer could just grab one.

eri0o


SMF spam blocked by CleanTalk