Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Add DirectoryRepository for local dependency installs #1462

Open
pauliwang opened this Issue · 8 comments

5 participants

@pauliwang

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

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

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
Owner

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

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

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
Owner

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

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

I think there is related PR #1728

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.