Local Repositories

[ncannasse]

The ability to have several haxelib repos on the same computer (and per-project setup) has been mentioned as part of the WWX discussions. Here we can discuss actual proposals on how this would work in practice before implementing it.

This might be as easy has allowing a ".haxelib" per project that would store the path to the used haxelib repo

[jasononeil]

I think a number of people prefer environment variables to ".haxelib" magic
files. I don't mind either way, but would really appreciate this feature.

(Is it worth having a simultaneous discussion about a Haxe version
manager? In ruby land RVM switches both the path of your libraries and the
path to the ruby version you use, so each project can depend on a specific
ruby version and a specific set of libraries. Could be handy if you have
projects on older Haxe versions, as our backwards compatibility isn't
always perfect.)

On Thu, May 29, 2014 at 9:46 PM, Nicolas Cannasse notifications@github.com
wrote:

The ability to have several haxelib repos on the same computer (and
per-project setup) has been mentioned as part of the WWX discussions. Here
we can discuss actual proposals on how this would work in practice before
implementing it.

This might be as easy has allowing a ".haxelib" per project that would
store the path to the used haxelib repo

—
Reply to this email directly or view it on GitHub
#141.

[ncannasse]

We can have the following:

haxelib local

Will setup a "local" repository (create a .haxelib directory)

then in haxelib, getRepository will look if there's a .haxelib directory first, and use it

I prefer that we have separate discussion about haxe version, I'm not sure it's related to haxelib

[jasononeil]

Ah, I see you mean having a ".haxelib" directory, rather than a text file
containing the directory location (which ~/.haxelib currently is).

I'm okay with that, though I'd be interested to hear what people with
experience with other package managers think.

On Fri, May 30, 2014 at 3:57 PM, Nicolas Cannasse notifications@github.com
wrote:

We can have the following:

haxelib local

Will setup a "local" repository (create a .haxelib directory)

then in haxelib, getRepository will look if there's a .haxelib directory
first, and use it

I prefer that we have separate discussion about haxe version, I'm not sure
it's related to haxelib

—
Reply to this email directly or view it on GitHub
#141 (comment)
.

[frabbit]

in nodejs world the version manager is done via npm package: see https://www.npmjs.org/package/n

[ncannasse]

Actually this is a bit more complex, since we want to have both local and global packages installed and usable together. I think this requires a major change which is to rename getRepository to getRepositories() which would return an Array of paths, and change all the commands accordingly

[jasononeil]

@ncannasse I prefer to deal with only one repository at a time. The reason for this:

• You know exactly which dependencies your project needs, and can copy them to a new workstation by copying only one folder, not two.
• You don't have any undocumented dependencies - it's easy to start with a "blank slate" local repository for a project and check that all dependencies install cleanly.
• No surprise changes in a global repository are going to affect your local repository.
• If one project needs a "dev" version it doesn't affect any other projects.

Having it fall back to a global repository in my opinion negates the purpose of having a local repository in the first place.

As for the actual suggestion - a ".haxelib" directory sounds like the easiest implementation to me, and we could change "getRepository()" to search for a ".haxelib" in the CWD or a parent directory, or use the defaults if not found. There's nothing to prevent a solution using environment variables from being added later.

[ncannasse]

How NPM does it ? single or multiple cascading repos ?

[impaler]

I would love haxelib to have functionality similar to npm, bower, rvm for local/global packages.
npm actually defaults to a local install if you dont specify:

npm install <package> -g global install

npm install <package> --save is a local install into ./node_modules directory. It also updates the package.json file with the package and version installed that overrides your global packages.

https://www.npmjs.org/doc/cli/npm-install.html
https://www.npmjs.org/doc/package.json.html

This is not the first time I have seen users ask for this feature https://groups.google.com/forum/embed/?place=forum/haxeflixel&showsearch=true&showpopout=true&showtabs=true&parenturl=http%3A%2F%2Fhaxeflixel.com%2Fforum%2F#!topic/haxeflixel/ZZwoEfxsjNc. A screenshot of haxelib list and a copy of your haxelib folder is far from intuitive.

[jasononeil]

They allow global, but it is discouraged:

http://blog.nodejs.org/2011/03/23/npm-1-0-global-vs-local-installation/

That post in general has some good insight on lessons they learned with
their package manager.

As for whether it looks up global when running a normal project, I'm not
sure - perhaps someone else can comment.

On Mon, Jul 14, 2014 at 4:52 PM, Chris notifications@github.com wrote:

I would love haxelib to have functionality similar to npm, bower, rvm for
local/global packages.
npm actually defaults to a local install if you dont specify:

npm install -g global install

npm install --save is a local install into ./node_modules
directory. It also updates the package.json file with the package and
version installed that overrides your global packages.

https://www.npmjs.org/doc/cli/npm-install.html
https://www.npmjs.org/doc/package.json.html

This is not the first time I have seen users ask for this feature
https://groups.google.com/forum/embed/?place=forum/haxeflixel&showsearch=true&showpopout=true&showtabs=true&parenturl=http%3A%2F%2Fhaxeflixel.com%2Fforum%2F#!topic/haxeflixel/ZZwoEfxsjNc.
A screenshot of haxelib list and a copy of your haxelib folder is far from
intuitive.

—
Reply to this email directly or view it on GitHub
#141 (comment)
.

[impaler]

@ncannasse sry for my crude understanding but if by cascading repos you mean _nested dependencies_ npm does this with their local and global node_modules folders to meet the dependencies each have, maybe this is what you mean?

project
        -> node_modules
            -> package 1
            -> package 2
                -> node_modules
                    -> package 3

[ncannasse]

I have implemented it using the following:

"haxelib new" will create a local repository (in your project root dir)
"haxelib delete" will delete the local repository (if there is any)

When you have a local repository, all your haxelib installs etc. are done in this directory.

I still have to handle the NDLL resolution in genNeko and I think Hugh will have to handle a similar thing in genCPP

[Simn]

I really don't like having both delete and remove with completely different semantics. :(

[ncannasse]

It's still time for change. I think we could at least error on delete if there is one extra argument, that should prevent some people from having regrets