Local packages about mpm HOT 6 CLOSED

Thank you for this detailed response. I understand the assumptions and architecture better now.

I'm going to close this issue as it requests a large change in architecture which would likely break things for users expecting things to stay the same.

Turns out the other package manager I'm looking at (https://github.com/OmidS/PackMan) already behaves exactly the way I'm asking for.

Thanks for your time @mobeets !

from mpm.

Thinking more about this, maybe each directory could be controlled by a declarative packages.json, ala https://github.com/OmidS/PackMan.

from mpm.

What do you mean exactly by installing locally? Could you give me a specific example of how what your use case is?

I think there are two options that might be related/useful. Let me know whether these are related at all to what you're talking about:

• you can install to a specific directory with the '-d' flag: mpm install matlab2tikz -d /Users/mobeets/mypath
• you can also create a collection of packages, basically functioning like a virtual env (though just a note, it currently only handles adding paths, not removing previously added ones--though i'd definitely like to fix this eventually)

from mpm.

Sure, since mpm models closely (in syntax) after npm, I'm thinking just how npm does it.

Default behavior is to install packages to a local node_modules directory. Only with the -g flag does it put packages in the default system-wide-accessible location.

With mpm, the default is to install to a system-wide location. And even if I choose a different directory, when I run mpm init from any directory, those packages are pulled onto the path.

My use case: I work on about 50 separate projects. Not all concurrently. Occasionally I have to drop into a project to do some work. With my current git submodules setup, I can drop into the project folder, run the main script which calls addpath() to setup the local submodules, and I'm off to work. (I have to manually clear out submodules from other projects if a restart is not involved).

It's not ideal, but it happens frequently that I'm using one commit of a submodule in one project, and another commit [of same module, think different releases] in another.

Because of this, mpm installing packages globally by default means I would need to do extra housekeeping (via collections or something) to get behavior that comes by default in npm.

I would like to standardize my main scripts/functions to call mpm init and have the paths setup just for that local project.

Maybe an extention to the default behavior of mpm init could be if a package.json is found in local directory, then install the dependencies found in there [to a local directory modules]. Just like npm. This would also take care of future extension for recursive handling by providing a standard for module configuration -- if the imported module has a package.json then parse it.

You could then add a field such as includeFolders with local paths to the folders to add to addpath for that package. This would solve your issue with there not being a standard layout for which paths to include.

from mpm.

Cool, I think I understand what you're going for. I think the difference in terms of default behavior comes from mpm being based off pip, which installs things globally by default (for better or worse). For package-specific installations you need a virtualenv, which is what the mpm collections are based off of.

Anyway, I think with the exception of where a project's dependencies are installed (more on that below), it sounds like the mpm collection will get you what you described, but correct me if I'm wrong:

>> [cd to your project folder]
>> mpm install cbrewer -c my_project % creates and installs to collection called 'my_project'
>> mpm install matlab2tikz -c my_project % installs to my_project
>> mpm init -c my_project % adds all paths for my_project

(If you wanted to handle the installation programmatically, you'd put these things inrequirements.txt.)

As for where these packages get installed, currently it's to a global location rather than inside the project itself. If there's a reason you would prefer things to be installed within your project directory instead, I think that would be an easy fix. Let me know if that's the case and I can take a stab at that soon-ish.

from mpm.

Nice, good to know it already exists!

from mpm.