You are browsing as a guest. Sign up (or log in) to start making projects!

mocha

  • 7 Devlogs
  • 16 Total hours

A package manager for Windows, compatible with scoop packages.

Open comments for this post

2h 15m 32s logged

Fuzzy search is really really good.

While implementing mocha search I noticed the results returned by scoop search were in alphabetical order, which doesn’t make a lot of sense. If I do scoop search git the first result should probably be git

As a result my implementation of search uses github.com/sahilm/fuzzy which is a small library which provides a fuzzy search implementation.

Scoop also checks for binary name matches, e.g. package biodiff can provide a binary called git-biodiff and show up in search results. I decided to remove this for now, since I personally find it a bit unnecessary.

scoop search also lists all search results, which is okay when results are sorted alphabetically but doesn’t make sense when searches are relevance based.

Therefore, by default mocha search will list exact matches plus the 20 most relevant search results. This can be overridden by the --count argument, where setting it to 0 displays all results.

A demonstration of mocha search vs scoop search can be seen in the video below.

Fuzzy search is really really good.

While implementing mocha search I noticed the results returned by scoop search were in alphabetical order, which doesn’t make a lot of sense. If I do scoop search git the first result should probably be git

As a result my implementation of search uses github.com/sahilm/fuzzy which is a small library which provides a fuzzy search implementation.

Scoop also checks for binary name matches, e.g. package biodiff can provide a binary called git-biodiff and show up in search results. I decided to remove this for now, since I personally find it a bit unnecessary.

scoop search also lists all search results, which is okay when results are sorted alphabetically but doesn’t make sense when searches are relevance based.

Therefore, by default mocha search will list exact matches plus the 20 most relevant search results. This can be overridden by the --count argument, where setting it to 0 displays all results.

A demonstration of mocha search vs scoop search can be seen in the video below.

Replying to @Glitchy

0
1
Open comments for this post

2h 9m 35s logged

I finished up mocha download, which surprisingly does a bit more than simply downloading files.

The first thing it does is well… download the file. This is a bit more complicated than it seems though, since we need to identify the right file to download based on cpu architecture. Hence the very cursed JSON parsing I had to create.

After downloading a file, we also do a hash check. We support the 4 types of file hashes which scoop support, those being sha256, sha512, md5 and sha1.

Currently files get downloaded to the $MOCHA_DIR/cache directory like in scoop, however we don’t actually check if there’s anything cached which can lead to repeated downloads. That’s something I’ll need to fix later on

I finished up mocha download, which surprisingly does a bit more than simply downloading files.

The first thing it does is well… download the file. This is a bit more complicated than it seems though, since we need to identify the right file to download based on cpu architecture. Hence the very cursed JSON parsing I had to create.

After downloading a file, we also do a hash check. We support the 4 types of file hashes which scoop support, those being sha256, sha512, md5 and sha1.

Currently files get downloaded to the $MOCHA_DIR/cache directory like in scoop, however we don’t actually check if there’s anything cached which can lead to repeated downloads. That’s something I’ll need to fix later on

Replying to @Glitchy

0
2
Open comments for this post

1h 24m 29s logged

I was working on the mocha download command so I can sort out fetching files, and during it I realized my current app format makes things a bit weird.

mocha cat previously took in a flag for bucket through -b and a name. Scoop on the other hand uses an application reference in the format bucket/name@version.

Scoop’s format is really important for downloads and installs, so it didn’t make sense to not standardize it between mocha download and mocha cat. Hence this shorter devlog! See the video below for the new usage (version numbers are ignored for mocha cat).

I was working on the mocha download command so I can sort out fetching files, and during it I realized my current app format makes things a bit weird.

mocha cat previously took in a flag for bucket through -b and a name. Scoop on the other hand uses an application reference in the format bucket/name@version.

Scoop’s format is really important for downloads and installs, so it didn’t make sense to not standardize it between mocha download and mocha cat. Hence this shorter devlog! See the video below for the new usage (version numbers are ignored for mocha cat).

Replying to @Glitchy

0
2
Open comments for this post

2h 58m 31s logged

I did a bit of refactoring to split the core functionality from the command files. This means that the code for downloading and deleting buckets is separated from the code for the various commands. I’m doing this primarily for better code organization, and also to prevent import cycles.

I also finished up the config system I mentioned last time. It’ll be one of the bigger improvements over scoop, which has a basic set of configuration options.

TOML was the obvious choice for the config format since it is really easy to read and write. I made sure that you can put it in any of the standard locations, such as %APPDATA% and .config or in $MOCHA_DIR.

Running mocha config will open the configuration in your preferred app, and also generate the default config if a configuration hasn’t been detected in any of the valid locations.

Currently the configuration can be used to make mocha cat run an external program for printing manifests to stdout. See the video below for an example using bat

I did a bit of refactoring to split the core functionality from the command files. This means that the code for downloading and deleting buckets is separated from the code for the various commands. I’m doing this primarily for better code organization, and also to prevent import cycles.

I also finished up the config system I mentioned last time. It’ll be one of the bigger improvements over scoop, which has a basic set of configuration options.

TOML was the obvious choice for the config format since it is really easy to read and write. I made sure that you can put it in any of the standard locations, such as %APPDATA% and .config or in $MOCHA_DIR.

Running mocha config will open the configuration in your preferred app, and also generate the default config if a configuration hasn’t been detected in any of the valid locations.

Currently the configuration can be used to make mocha cat run an external program for printing manifests to stdout. See the video below for an example using bat

Replying to @Glitchy

0
10
Open comments for this post

2h 36m 53s logged

So this is a spot where I think the improvements over scoop start becoming really apparent.

The scoop cat command simply prints an app’s manifest to console. However due to the long startup time of PowerShell scripts (scoop is written in PowerShell) basic stuff like scoop cat takes a second.

mocha cat on the other hand is nearly instantaneous since it’s a compiled binary with almost 0 startup time.

You can see how this plays out in real usage in the video below. I also half baked a config system, but it’s not finished so I’ll talk about that in the next devlog.

So this is a spot where I think the improvements over scoop start becoming really apparent.

The scoop cat command simply prints an app’s manifest to console. However due to the long startup time of PowerShell scripts (scoop is written in PowerShell) basic stuff like scoop cat takes a second.

mocha cat on the other hand is nearly instantaneous since it’s a compiled binary with almost 0 startup time.

You can see how this plays out in real usage in the video below. I also half baked a config system, but it’s not finished so I’ll talk about that in the next devlog.

Replying to @Glitchy

0
2
Open comments for this post

2h 51m logged

I finished off the remaining mocha bucket subcommands, those being add, rm and list. These commands manage “buckets” which are pretty much just package sources.

mocha bucket add uses git to clone the relevant bucket into the [MOCHA_DIR]/buckets directory. By default MOCHA_DIR is [USER]/mocha

mocha bucket list simply loops over the [MOCHA_DIR]/buckets directory and gets relevant info for each bucket.

mocha bucket rm removes a bucket by just deleting the folder containing the bucket. For example, removing the main bucket deletes [MOCHA_DIR]/buckets/main

I finished off the remaining mocha bucket subcommands, those being add, rm and list. These commands manage “buckets” which are pretty much just package sources.

mocha bucket add uses git to clone the relevant bucket into the [MOCHA_DIR]/buckets directory. By default MOCHA_DIR is [USER]/mocha

mocha bucket list simply loops over the [MOCHA_DIR]/buckets directory and gets relevant info for each bucket.

mocha bucket rm removes a bucket by just deleting the folder containing the bucket. For example, removing the main bucket deletes [MOCHA_DIR]/buckets/main

Replying to @Glitchy

0
2
Open comments for this post

2h 1m 34s logged

I started off with something a bit simple: mocha bucket known

The known bucket list in scoop is a list of buckets which are known by the package manager in advance. These buckets don’t require the full URL to be used when using scoop bucket sub-commands.

For example instead of running scoop bucket add https://github.com/ScoopInstaller/Main you can instead run scoop bucket add main

As seen in the video below, mocha bucket known doesn’t do much. First it downloads buckets.json if it doesn’t exist. Then it parses the json and outputs it to console.

I started off with something a bit simple: mocha bucket known

The known bucket list in scoop is a list of buckets which are known by the package manager in advance. These buckets don’t require the full URL to be used when using scoop bucket sub-commands.

For example instead of running scoop bucket add https://github.com/ScoopInstaller/Main you can instead run scoop bucket add main

As seen in the video below, mocha bucket known doesn’t do much. First it downloads buckets.json if it doesn’t exist. Then it parses the json and outputs it to console.

Replying to @Glitchy

0
3

Followers

Loading…