Support for Composer package in sub-directory of GitHub repo

[bdferris]

I have a multi-language project in a GitHub repo (https://github.com/google/gtfs-realtime-bindings/) that has a php/ subdirectory containing a composer.json file. Best I can tell, there is no way to generate a Packagist package from my repo given this configuration. Any chance this is a scenario you would consider supporting?

[Seldaek]

This is very unlikely because it'd be kinda hard to find those files via the github API unless we do a full listing of all dirs and that'd slow down all our updates quite a lot.

[Rastusik]

what about manually setting the path in a form on the packagist server?

[edertone]

I have a multi language project too and moving the composer.json to the root of the git repository would break the project structure. I think that is not so difficult to allow us to provide some relative path inside the repository so packagist can find the composer.json if it is not on the root of the repo...

[sffc]

Please reopen this issue. This restriction causes major headaches for both users and maintainers of composer projects.

[buffcode]

This would also help with MonoRepos such as symfony/symfony as the projects would not necessarily needed to be split up into single repositories.
In our use case we have a mono repository with ~20 internal projects which should be able to be installed independently. In order to install them, we have to split them into separate repositories and publish them.

Using git clone --filter or sparse checkouts in combination with the path input (#472 (comment)) would result in a valid composer project.

[stof]

@buffcode given that packagist does not generate its own archives but relies on the github archives for downloads, downloading components directly from the mono-repo would not be possible. This would require a major change in the architecture of packagist to allow that.

[edertone]

@buffcode given that packagist does not generate its own archives but relies on the github archives for downloads, downloading components directly from the mono-repo would not be possible. This would require a major change in the architecture of packagist to allow that.

Time to start looking for better dependency management alternatives then. It is sad to see how composer is years behind from other systems like NPM in terms of features and flexibility

[JoanBotella]

I think it is important to allow having the composer-related files and directories in a project subdirectory, in order to avoid a root directory full of unorganized configuration files. Maybe it could be done using a composer.json directive or through some kind of form on Packagist. For example, on creating the package on Packagist, alongside with the remote repository URL the composer.json path could be asked too.

[Marat-Tanalin]

@Seldaek

This is very unlikely because it'd be kinda hard to find those files via the github API unless we do a full listing of all dirs and that'd slow down all our updates quite a lot.

Does this matter when a developer submits a specific package URL to Packagist manually anyway?

Instead of:

https://github.com/developer/project

we could just submit a subdir URL:

https://github.com/developer/project/tree/master/subdir

[nextgenthemes]

Probably an off-topic question but this seems to be about packagist. Is there any way to do this with composer with code from GitHub I have full control over? Meaning I can place the composer.json in root or also in the dir I actually want to install?

Composer has something like post install scripts I think. Maybe there is a way to do this for code that is actually NOT on packagist?

Or maybe there is some workaround? I guess I could configure a package to install into /tmp and then just copy the desired folder.

[lcdss]

This would be really great for monorepos e doesn't need to slow down anything if the url will give all the info needed.

[Furgas]

Dang, and I was excited I could switch to GIT and won't need tons of readonly repos with my monorepo and tools to synchronize them. Maybe I will stay with Subversion as composer supports this feature with "package-path" (so it is not a new concept).

[zolex]

it is possible with a little workaround:

just place a composer.json similar to this one in the project root:

{
    "type": "project",
    "name": "my/package",
    "license": "proprietary",
    "minimum-stability": "stable",
    "prefer-stable": true,
    "scripts": {
        "post-create-project-cmd": [
            "rm -rf composer.json vendor",
            "composer install -d path/to/folder/with/composer.json/in/it"
        ]
    }
}

[stof]

@zolex this might work when the project is in a sub-directory (and your package is only used as a template to start the project). But not for packages meant to be used as dependencies

[ijry]

other lang all support pub a subdir as a extention to package manager，such as java/node/python/.net，reallly need this feature.

[LLyaudet]

Hello @Seldaek :)
This was closed more than 9 years ago but we are still many to think it would be needed.
Any chance you may revert your decision ?, especially now that a similar code has been done
by @vtsykun in packeton : vtsykun/packeton#68 ?
Thanks if you take the time to answer us, best regards,
Laurent Lyaudet

[edertone]

agree

[ijry]

agree

[djvickx]

There is one way to achieve it, you can use .gitattributes files and you can define in that file those folders/files that you want composer to ignore at the time when someone requires the library in the project.
Like e.g. if you add the following line in .gitattributes file:
tests export-ignore
It will ignore the tests folder and all those files/folders mentioned in the file will be a part of your library source code but those won't be included by composer at the time user downloads the library.

[LLyaudet]

Hello @djvickx ,
I don't think what you suggest is a true solution.
It still requires to add files at the root of the git repository,
instead of having composer look only in the dedicated subfolder.
A true solution is still needed.
Best regards,
Laurent Lyaudet

[djvickx]

Hi @LLyaudet, I agree its not a true solution and it doesn't work for the sub directories in case of composer file is in a sub directory but its a work around atleast to remove files/folder on the same root level.

[LLyaudet]

Hello @djvickx,

I understand your point of view.
But you did not add a thumbs up to my message:

Hello @Seldaek :)
This was closed more than 9 years ago but we are still many to think it would be needed.
Any chance you may revert your decision ?, especially now that a similar code has been done
by @vtsykun in packeton : vtsykun/packeton#68 ?
Thanks if you take the time to answer us, best regards,
Laurent Lyaudet

You wanted to help, but the true solution is just to add the feature that is needed.
In my point of view, people should be redirected to my message above and add thumbs up there, so that it is clear that we are many thinking it is a good idea to add a missing major feature to enable mono-repositories.
So please, just add thumbs up here if you think it is a good idea:
#472 (comment)
Otherwise, this is just noise, whatever the intent.

Best regards,
Laurent Lyaudet

[djvickx]

Hi @LLyaudet,
Agreed and added thumbs up to your original comment and the recent one as well.
Cheers!

[vtsykun]

Hi @LLyaudet

To support this function by Packagist.org, changes will be required from GitHub API. Currently zipball GitHub api does not allows downloads source code archives for specific path prefix in git repository.

But Packeton in first clone git repository to local cache and use command git archive --prefix=path_pref to build archive for monolithic repo locally. This approach is not very applicable for public repositories like Packagist.org due to problems with horizontal scalability and infrastructure cost

[LLyaudet]

Hello @vtsykun

This approach is not very applicable for public repositories like Packagist.org due to problems with horizontal scalability and infrastructure cost

I don't have all the elements to see if you're right or if you're wrong.
But I know two things:

• Adding the feature needed in GitHub Api should not be hard;
• Otherwise it is easy to have another process included in packagist to upload a package manually exactly like you do in PyPI.

Easy solutions exist, no solution is from people don't want some solutions.

Best regards,
Laurent Lyaudet

[offizium-berndstorath]

The points here are invalid at best. Many other package repos support uploading the package directly from e.g. Github Actions. So not supporting this is plain naiveness