Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Display current repository path when using haxelib list #634

Open
wants to merge 11 commits into
base: development
Choose a base branch
from

Conversation

ninjamuffin99
Copy link
Contributor

Adds a file system check for a .haxelib directory in GlobalScope.hx (there's no LocalScope.hx class), and then sets isLocal accordingly.

Then in the Main.list() function, we check for isLocal being true or false. We display Local Haxelib Repository at: {localPath} if we are in local scope, and Global Haxelib at: ${RepoManager.getGlobalPath()}\n

also slightly change the way that list works, appending just one string and printing a single string to the CLI, rather than printing each string individually

In the root of FNF (.haxelib directory exists)
image

In the assets/ folder/submodule of FNF (.haxelib directory does not exist
image

@kLabz kLabz self-requested a review July 30, 2024 18:55
Copy link
Contributor

@kLabz kLabz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Local scope is not only for when there's a .haxelib folder in current repository (can be in any parent directory, too), and in this case:

  • this PR considers the repo as global while it's not
  • it breaks if global scope isn't setup

@ninjamuffin99
Copy link
Contributor Author

This needs to handle the case where global scope doesn't exist.

just double checking, global scope is where haxelibs get installed to, and gets set up via haxelib setup?

@kLabz
Copy link
Contributor

kLabz commented Jul 30, 2024

Yes (well, where haxelibs get installed to when you don't have a local repository). But you can also only ever use local repositories and never setup global repository to avoid mistakenly installing libs globally.

@ninjamuffin99
Copy link
Contributor Author

nice, just made change that uses RepoManager.getPath() which recursively looks for a local haxelib repository. This removes my old method of looking for .haxelib specifically.

Then it compares whatever path it finds to the global repository path via RepoManager.getGlobalPath(). If it matches, it assumes that it's not local.

I'll now poke around into making sure that it works without a global scope setup!

@ninjamuffin99
Copy link
Contributor Author

so it's possible to have a local repo without having setup a global one? So this command should respond accordingly and work in local repos on machines with no global repo?

@@ -21,6 +23,9 @@ using StringTools;
class GlobalScope extends Scope {
function new(repository:Repository) {
super(false, repository);

// While this class is "GlobalScope", there's currently not a "LocalScope" equivalent class. For now we can add this here.
isLocal = repository.path != RepoManager.getGlobalPath();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, RepoManager.getGlobalPath() will throw if there's no global repository setup.

This not so pretty hack might not be a good idea..
isLocal should probably live in Repository itself, which could also more easily identify local / global cases (might need to rework get() a bit there).

@ninjamuffin99
Copy link
Contributor Author

ninjamuffin99 commented Jul 30, 2024

some changes

  • moved the isLocal set code from GlobalScope.hx to Scope.hx
  • removed the isLocal arg from new Scope() and the super() in new GlobalScope(), since we determine if it's local or not depending on the directory information + config information

When running haxelib list with no global scope, it behaves as normal, telling you that you should run haxelib setup. But if you have no global scope but run haxelib list inside a local repository (or a recursive subdirectory of a local repository) it will properly list out the local repositorys haxelibs. In other words, should function identically to current haxelib list implementation

note: i have only tested global non-setup by renaming my lib folder thats inside usr/local/lib/haxe/ folder, where it properly errors out Error: haxelib Repository /usr/local/lib/haxe/lib does not exist. Please run 'haxelib setup' again when attempting to run haxelib list outside of a local repository. If there's an edge case where it might bypass or work differently, I'll look into that

@ninjamuffin99
Copy link
Contributor Author

ninjamuffin99 commented Jul 30, 2024

took a peak at some of those failed tests just now.

  • TestDev.testPreferenceOfHaxelibJsonName() wants the output to start with the name of the library (style of current haxelib list)
  • TestList.testInvalidDirectories() expects nothing in the output, currently returns the new Repository at: message

Not to schmooze around the tests too much, what are some options to get these passing? I will say, I don't know testing etiquette! Off the top of my head, maybe can pass --quiet to these specific tests, and when --quiet gets passed through, it suppresses the Repository at: {path} message, which maybe can be helpful if people want to do parsing on their haxelib list output in general.

@kLabz
Copy link
Contributor

kLabz commented Jul 30, 2024

Yeah, haxelib list parsing is one of my concerns, too.

@ninjamuffin99
Copy link
Contributor Author

  • passing through --quiet to haxelib list will suppress the new line regarding current scope
  • modified the failing tests to pass through --quiet as an arg, which will display the previous haxelib list "styling" (hopefully!)

@tobil4sk
Copy link
Member

Adds a file system check for a .haxelib directory in GlobalScope.hx (there's no LocalScope.hx class), and then sets isLocal accordingly.

The isLocal member in the Scope class refers to a different concept than global/local repositories.

Repository - a place where libraries are installed, can hold multiple versions of the same library.

  • global: all libraries are stored in a folder accessible from anywhere on the system.
  • local: all libraries are stored in a .haxelib folder somewhere up the directory tree.

Scope - something takes a library name and tells you which version of that library to use.

  • global: versions are specified in .current files (which currently happens to be in the repository).
  • local: not implemented yet, but in future library versions may be stored in a project specific file, so that a project can specify which library versions it wants to use.

isLocal refers to global/local scopes, not global/local repositories.

@ninjamuffin99
Copy link
Contributor Author

ah that makes total sense. Knowing what I know now, I'll entirely ignore isLocal, and simply run the "local check" in the list() function itself, keeping Scope.hx and GlobalScope.hx untouched

@ninjamuffin99 ninjamuffin99 changed the title Display current scope when using haxelib list Display current repository path when using haxelib list Aug 5, 2024
@skial skial mentioned this pull request Aug 7, 2024
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants