Jump to content




Grin-Get - A Grin based Package Manager


18 replies to this topic

#1 ElvishJerricco

  • Members
  • 803 posts

Posted 03 October 2014 - 05:07 AM

Grin-Get - Package Manager


I recently created a tool called Grin. It's a lightweight interface to downloading releases from GitHub. Grin is nice because it lets developers create complex projects without worrying about complex installation processes for users. Instead all that's needed is a zip file of what's supposed to be installed on the user's computer. Then you make an installer that invokes Grin (through pastebin) with the proper arguments and Grin takes care of downloading, decompressing, and saving the installation to disk.

Grin-Get is a package manager based on Grin. Unlike Grin, which is meant to be lightweight and transparent to the user, Grin-Get is an interface for the user that manages the installation of packages and the interactions between them.

Github
Pastebin installer: HGAmBJiN

Usage
grin-get {install : remove} ...
  • grin-get install {package}
    This command is used to install a package. Packages are denoted by the username and repo name for the project on GitHub. e.g.
    grin-get install Team-CC-Corp/Grin
    By default, grin-get installs the latest version of the package, but this can be changed by specifying a version, like this:
    grin-get install Team-CC-Corp/Grin/1.0.1

    Grin-Get can install any Grin compatible release. No special action is needed from developers if the developer wants Grin-Get support on top of their Grin support. This is nice because it's already easy and powerful for a developer to support Grin, and this way they can support installation independently of Grin-Get. So they can keep their installation process transparent to the user if they don't want to require Grin-Get, while still supporting Grin-Get.
  • grin-get remove {package}
    This is rather straightforward. It simply deletes the package from the packages folder.
Opt-In Features
Grin-Get does provide some features developers might want, but these features only work through Grin-Get, not through ordinary Grin. Packages that make use of these features require installation via Grin-Get.
  • grin.json
    Spoiler
  • The grin API
    Spoiler
Installation
Grin-Get is installed via a pastebin based Grin installer. Just run:
pastebin run HGAmBJiN
And Grin-Get should be installed. But you need to add something like the following to your startup file
shell.run("grin/bin/grin-startup.lua")
Because Grin-Get needs to do a couple things as the computer starts up to allow you to use your packages easily.

Edited by ElvishJerricco, 03 December 2014 - 06:17 AM.


#2 Mr. Bateman

  • Members
  • 98 posts
  • LocationAustralia

Posted 03 October 2014 - 07:12 AM

Seems pretty neat. It's a shame though that the community isn't large enough to keep the momentum with package managers.

#3 ElvishJerricco

  • Members
  • 803 posts

Posted 03 October 2014 - 02:14 PM

View PostMr. Bateman, on 03 October 2014 - 07:12 AM, said:

Seems pretty neat. It's a shame though that the community isn't large enough to keep the momentum with package managers.

Yea. That's why I think quick and easy installation is essential. Grin is the main idea here, since that's completely transparent and users don't even have to realize they're using it. But Grin-Get was just the logical evolution.

#4 ElvishJerricco

  • Members
  • 803 posts

Posted 07 October 2014 - 08:45 AM

Updated. Changes:
  • Added grin.packageFromExecutable -- gets the package name from an executables full path.
  • Added support for help paths.
  • Startup files are run in parallel.
  • Support a special "dev" version of a package. Use for development of a Grin-Get dependent package.


#5 ElvishJerricco

  • Members
  • 803 posts

Posted 10 October 2014 - 11:22 AM

Update. Changes:
  • Fixed getPackageAPI
  • Updated Grin version
  • Error instead of printError() return;


#6 ElvishJerricco

  • Members
  • 803 posts

Posted 12 October 2014 - 05:59 PM

Updated. Changes:
  • Added __package variable in API environments so they can identify their packages.


#7 ElvishJerricco

  • Members
  • 803 posts

Posted 04 November 2014 - 05:42 AM

Updated. Bug fix

#8 ElvishJerricco

  • Members
  • 803 posts

Posted 03 December 2014 - 06:18 AM

Updated: Transferred ownership to the new team Yevano and I have started.

#9 Phoenix323

  • Members
  • 30 posts
  • LocationAustralia

Posted 16 December 2014 - 01:03 AM

i just keeps looping and looping over and over

#10 ElvishJerricco

  • Members
  • 803 posts

Posted 16 December 2014 - 06:02 AM

View PostPhoenix323, on 16 December 2014 - 01:03 AM, said:

i just keeps looping and looping over and over

Going to need more detail than that. Also note that larger packages (JVML is very large) can take some time to unarchive.

#11 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 11 April 2015 - 10:24 AM

Following on from this post, I thought it'd be fun to see how my own packager fared with the JVML folder. It didn't do very well, of course (something like 260kb once uploaded - you've got decent-sized pre-compressed jar in there which throws a bit of a spanner into the works), but in order to get a copy of JVML I had to go through Grin.

The thing that surprised me was how slow Grin was. I realise a lot of that has to do with the rather more processor-intensive operations involved in unpacking zips, but I decided to dig around in case there was anything obvious you could do to improve matters.

I noticed that you're using os.time() to track when you should yield - that function should be avoided unless you actually want to know the MineCraft time. Your script will fail if the user happens to run it just before midnight, because os.time() will suddenly go from ~23.something to ~0.something, and Grin will hence decide that it doesn't need to yield for the next day. Use os.clock() instead - that'll keep increasing until the system reboots. You may even consider simply yielding whenever a certain part of your loop structures are passed over, without bothering to check the time at all.

Speaking of which, when you yield, consider avoiding sleep(0). This wastes a tick, as timers take a minimum of a twentieth of a second to fire their events. Queue a custom event instead (eg tostring({})) then pull that.

#12 MKlegoman357

  • Members
  • 1,170 posts
  • LocationKaunas, Lithuania

Posted 11 April 2015 - 01:26 PM

View PostBomb Bloke, on 11 April 2015 - 10:24 AM, said:

Speaking of which, when you yield, consider avoiding sleep(0). This wastes a tick, as timers take a minimum of a twentieth of a second to fire their events. Queue a custom event instead (eg tostring({})) then pull that.

If you only need to yield, then creating a table, tostring'ing it and queuing it, then pulling an event with a filter can be relatively slow. Just queue an empty string and pull any event, works faster than anything else.

os.queueEvent("") os.pullEvent()

Edited by MKlegoman357, 11 April 2015 - 01:26 PM.


#13 ElvishJerricco

  • Members
  • 803 posts

Posted 11 April 2015 - 05:08 PM

View PostBomb Bloke, on 11 April 2015 - 10:24 AM, said:

- snip -

Thanks for the tip!

#14 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 11 April 2015 - 11:43 PM

View PostMKlegoman357, on 11 April 2015 - 01:26 PM, said:

If you only need to yield, then creating a table, tostring'ing it and queuing it, then pulling an event with a filter can be relatively slow.

Good point. I've kinda gotten into the habit of trying to flush the whole queue out, but there's really no "need" for that.

#15 ElvishJerricco

  • Members
  • 803 posts

Posted 12 April 2015 - 12:14 AM

Bomb Bloke said:


There'd be a lot more that I could do to speed up grin if CC supported file seeking. As it stands, the big reason it takes so long is because it loads the entire zip file into memory in one go, than traverses back and forth over that one huge table. But without file seeking, there isn't really another way.

#16 Bomb Bloke

    Hobbyist Coder

  • Moderators
  • 7,099 posts
  • LocationTasmania (AU)

Posted 12 April 2015 - 12:29 AM

Eh what? Seeking through a table loaded in RAM is always going to be faster than seeking through a file. :blink:

#17 ElvishJerricco

  • Members
  • 803 posts

Posted 12 April 2015 - 01:32 AM

View PostBomb Bloke, on 12 April 2015 - 12:29 AM, said:

Eh what? Seeking through a table loaded in RAM is always going to be faster than seeking through a file. :blink:

But there's extra steps added by having to scan the whole file once before getting to actually use it. Rather than finding the end of the zip file for the directory table, finding files, and seeking to them to read them directly, I have to load the entire thing once, reading one time, then I have scan around for the directory, then I can read from memory. It's slower.

#18 CrazedProgrammer

  • Members
  • 495 posts
  • LocationWageningen, The Netherlands

Posted 20 June 2017 - 03:16 PM

Hi ElvishJerrico,

I'm having issues getting grin-get installed.
It seems to have to do with the JSON library not downloading correctly:
Posted Image
Any idea how I could fix this?

#19 SquidDev

    Frickin' laser beams | Resident Necromancer

  • Members
  • 1,427 posts
  • LocationDoes anyone put something serious here?

Posted 20 June 2017 - 03:17 PM

View PostCrazedProgrammer, on 20 June 2017 - 03:16 PM, said:

Hi ElvishJerrico,

I'm having issues getting grin-get installed.
It seems to have to do with the JSON library not downloading correctly:
This is fixed on the latest version, which hasn't been released yet. I'll try to get round to that later today. Sorry.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users