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

Local Repositories #141

Closed
ncannasse opened this issue May 29, 2014 · 22 comments
Closed

Local Repositories #141

ncannasse opened this issue May 29, 2014 · 22 comments
Assignees
Milestone

Comments

@ncannasse
Copy link
Member

@ncannasse ncannasse commented May 29, 2014

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
Copy link
Contributor

@jasononeil jasononeil commented May 30, 2014

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
Copy link
Member Author

@ncannasse ncannasse commented May 30, 2014

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
Copy link
Contributor

@jasononeil jasononeil commented May 30, 2014

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
Copy link
Member

@frabbit frabbit commented May 30, 2014

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

@ncannasse
Copy link
Member Author

@ncannasse ncannasse commented Jul 13, 2014

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
Copy link
Contributor

@jasononeil jasononeil commented Jul 14, 2014

@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
Copy link
Member Author

@ncannasse ncannasse commented Jul 14, 2014

How NPM does it ? single or multiple cascading repos ?

@impaler
Copy link

@impaler impaler commented Jul 14, 2014

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
Copy link
Contributor

@jasononeil jasononeil commented Jul 14, 2014

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
Copy link

@impaler impaler commented Jul 22, 2014

@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
Copy link
Member Author

@ncannasse ncannasse commented Dec 9, 2014

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

@ncannasse ncannasse closed this Dec 9, 2014
@Simn
Copy link
Member

@Simn Simn commented Dec 9, 2014

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

@ncannasse
Copy link
Member Author

@ncannasse ncannasse commented Dec 9, 2014

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

@ncannasse ncannasse reopened this Dec 9, 2014
@ncannasse
Copy link
Member Author

@ncannasse ncannasse commented Dec 9, 2014

Another option is to do "haxelib local create/delete" , but "local" is already used to install a zip file (we could rename this one, it's rarely used. But I think that local repo creation should be kept short.

@Simn
Copy link
Member

@Simn Simn commented Dec 9, 2014

+1 "haxelib local create/delete"

It's really descriptive and leaves no room for misinterpretation. I support your quest for brevity but here it's much more important to have a clean interface.

@andyli
Copy link
Member

@andyli andyli commented Dec 10, 2014

+1 on more descriptive command.

@back2dos
Copy link
Member

@back2dos back2dos commented Dec 10, 2014

Stupid question, but why do we need commands for this at all?
Use haxelib local create today with mkdir .haxelib :P

The current implementation is also rather thoughtless:

  1. if you haxelib install in a subdirectory (and I so see myself doing that), it goes to global rather than through local
  2. if you have to install openfl+hxcpp+... for each project, it's not so much fun
  3. if you run haxelib run xyz, it requires a local copy of the lib. So among other things this means you can't start HIDE from your project directory, unless you re-install it (and therefore also node-webkit) in the local libs.
  4. haxelib selfupdate in a project with a .haxelib folder will do really weird things, most likely breaking the haxelib command (at least outside the folder).

More importantly, I don't see how this improves on the currently existing functionality. You can always specify exact dependencies in your hxml and use haxelib install hxml to then install just those. Not only does that make your state truly stable, it also makes it replicable and trackable in source control.

But with this recent addition, as it is on the table now, we are effectively adding a command that makes it cheaper to create fragile irreplicable states. We already have people complaining that the examples they find are hard to get working.

@ncannasse
Copy link
Member Author

@ncannasse ncannasse commented Dec 10, 2014

I was thinking renaming "remove" to "uninstall" (it's rarely used I guess), so we have the new/delete and install/uninstall

@back2dos with all due respect, I will not accept any complain that is not backed by a pull request, since the issue has been stalled for months :) The concept of local unique repository seems to be the default with NPM (note : I have never used NPM myself), so if it works with other people, it works for me.

@frabbit
Copy link
Member

@frabbit frabbit commented Dec 10, 2014

i like "haxelib local create/delete"

@back2dos
Copy link
Member

@back2dos back2dos commented Dec 10, 2014

@ncannasse My point is, you have committed code that introduces defective behavior (see point 4). My pull request would revert your commit. Full stop. As I have already explained, the possibility of a per-project setup is given. I am not saying it couldn't be better, but simply that you are not making it better. I am opposed to changes that create more problems than they solve and its current state, this is one of them. I have voiced my concerns. Make of it what you wish. When the people start raising the issues I did, we can't tell them them to make pull requests, can we?

I don't want to drag this out into a discussion and I won't even bother to respond to that npm bit. I'm just saying you didn't get it right. On the list you said "Feedback appreciated". This is my feedback. Where's your appreciation? :P

@Simn
Copy link
Member

@Simn Simn commented Dec 10, 2014

We have to check/address the potential selfupdate issue. Other than that this is a good start. It's certainly better than having nothing at all.

I kind of would like to allow a global fallback, but it's not crucial for me.

@back2dos
Copy link
Member

@back2dos back2dos commented Mar 15, 2015

Ok, after talking with @ncannasse we're adding this. I have fixed the selfupdate issue and added a --global switch that allows to fall back to the global repo from a local one (might be useful for haxelib run).

I have also talked with @jasononeil and we intend to pursue a different strategy. More on that later though.

@back2dos back2dos closed this Mar 15, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
7 participants
You can’t perform that action at this time.