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

Already on GitHub? Sign in to your account

Add DirectoryRepository for local dependency installs #1462

pauliwang opened this Issue Jan 8, 2013 · 9 comments


None yet
5 participants

pauliwang commented Jan 8, 2013

It would be great to be able to add a package that resides on the local filesystem by just pointing to the directory that it's located in. The url could be a file url that points to the local directory with the composer.json file.

For example

"repositories": [
    "type": "directory"
    "url": "file:///path/to/dir/that/contains/composer.json/"
    "symlink": true

The 'symlink' attribute would control whether the files are copied or symlinks to the original. The advantage of providing the 'symlink' attribute is if you control the package that you are dependent upon but don't want to have to go through the hassle of updating the root package every time you make a change to the dependent package. This option would aid in speeding up development.


igorw commented Jan 8, 2013

Another note: there should be a version option, so that you can specify the version inline for local dirs that have no version specified.


stof commented Jan 8, 2013

not updating the root package when the other package is updated means that the lock file does not correspond to the code you are actually using. This looks wrong to me as soon as you have 2 devs in the team (or 1 dev and a deployment server)


Seldaek commented Jan 8, 2013

You can already do a {"type":"vcs", "url":"file:///path/to/git/repo"} which will work fine locally, so I don't really see the added benefit of this feature. What's the use case you are trying to solve?


pauliwang commented Jan 8, 2013

This is mainly for the case where you're not using a distributed vcs and don't want to check in changes just to be able to test them. With git, I can see how using a file url directly would be easier.

If you're using svn, however, you have to check in your changes to the main svn repository before you can even test it. There's no way to bring in a unchecked-in dependency unless you make a zip-compessed package repository.

The symlink option is for when you have control over the packages you depend on. For example, root package A depends on package B and C. You control all 3 and want to make changes in B and C and see how they affect A without checking in B and C. The iterative process of development and local testing will be more efficient with something like a symlink package.

You can also imagine having a deployment package and a test package where the test package depends on the deployment package. You wouldn't want to have to check in the deployment package first before testing things on a test package.

You're right that with a distributed vcs, these points become moot, but not everyone is on a distributed vcs yet.


pauliwang commented Jan 8, 2013

Just wanted to clarify what I meant by a test package and deployment package. A test package would contain unit test code that exercised code in the deployment package, hence the test package would depend on the deployment package.


Seldaek commented Jan 9, 2013

Well I can see some value in it, but it's also a big opportunity to shoot yourself in the foot. And I am not sure how it would handle updates at all.. Does it just copy the files over every time you run update (obviously with symlink it's easier)?


pauliwang commented Jan 9, 2013

Yes, it should just copy files over. For symlink packages, it should actually remake all symlinks in case files were added or deleted.

Packages with DirectoryRepository dependencies should be rejected from any central composer repository (packagist, satis).


nfx commented Mar 25, 2013

I think there is related PR #1728

@Seldaek Seldaek closed this Apr 12, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment