@stevedennis said in PHP Composer feed connect to vcs type repository or how to upload:
Hi.
Thank you for answering.
So, our Composer feed is relatively new, so we are open to exploring new ideas. One option might be to do an "import" of packages into ProGet, similar to how we handle connectors in Terraform feeds.
Where do you import from? We are interested in importing from git. Because git is the original source of the code. And after publishing a tag or branch, we need to create a version of the corresponding tag. Otherwise, we will need some kind of layer that will extract metadata and packages. Aka packagist or satis.
That said, we definitely can't implement "content pointers" to Git repositories. The Git-based "package" model is not only outdated but it has several "fatal" Software Supply Chain problems.
I have a feeling that I've been transported back 35 years, when people carried 5-inch floppy disks with files to each other.
The biggest problem, by far, is that package content is hosted by a third party (i.e. GitHub) and managed by another third party (i.e. the repository owner). At any time, a package author or the host can simply delete the repository and cause a major downstream impact - like the infamous left-pad incident in npm.
Why does this bother you? If someone wants to set up a connector for a repository, they have the right to do so. If the repository disappears, it's no problem to find a new fork. We live in a global world. Once information becomes public, it doesn't disappear.
This is why other package ecosystems have adopted a "read only" package repositories and disallow deletes (except for rare cases like abuse). Once you upload a package to npmjs, nuget, rubygems, etc. -- it's permanently there, and users can always rely on that being the case.
These are all problems with public repositories. I have a private repository.
That's simply not possible with Git-based "packages". The "content pointer" must be updated periodically updated, such as if the author decides to move the Git repo to GitLab, Gitea, etc. Now you no longer have a read-only package repository, but one that must be editable. Who edits? Are they tracked? What edits are allowed? Etc.
This is not a problem at all and is not related to the topic of the question.
There are several of other issues, especially with private/organizational usage, like the fact that there's no reasonable way to QA/test packages (i.e. compared to using a pre-release/repackaging workflow) and that committing/publishing are coupled (i.e. you tag a commit to publish it). This makes governance impractical.
I wonder how all the developers and QA work? This answer wasn't generated by AI? :)
And that's not to mention the fact that there's no real way to "cache" or "privatize" third-party remote Git repositories. Unless, of course, you mirror them into your own Git server... which is technically challenging, especially if the author changes hosts.
We first investigated feeds years ago, but they didn't have package files at the time -- only Git repository pointers. Like Rust/Cargo (which used to be Git-based, and still technically supports Git-based packages), we anticipate this same maturity coming to Packagist/Composer as well.
I hope this never happens.
So while we certainly understand that this is a workflow shift, it's a natural evolution/maturation of package management. Likewise, it took decades for the development world to shift from "file shares" and legacy source control to "Git", but that's what everyone has standardized on.
That's the world ProGet operates in, so it might be a bit "too far ahead", or we might be misreading the tea leaves - but a "package mindset" is a requirement in using ProGet. But hoepfully we can make that easier, possibly with exploring "package imports" or something like that.
I realized that we have slightly different views. And in the case of binary data (docker image for example, or rpm, deb) packages make sense. But in the case of code, going back to files is a step backwards. SCM (git) has a lot of advantages over zip. Composer can download as zip, which is a container for transportation. And the original code is always stored in SCM (git).
It was expected that ProGet would be able to replace packagist.org for private repositories and we would be able to use a single system for our composer packages, rpm, docker images, helm charts, terraform modules and statates. But with the composer, there is still a problem and it is a blocker to migrate to ProGet.
Thank you for trying to help.
--
WBR,
Viacheslav Dubrovskyi