autoload.php isn't created correctly about nexus-repository-composer HOT 5 CLOSED

Hello, @TheBay0r! I've actually been out on vacation the past week and haven't been checking up on all this. And your help and support is very appreciated and always welcome by me.

My suspicion, like yours, is that we need to have that data in the package info we're sending back in order for the autoload and dependency resolution to work as expected, and that the "minimum" package definition detailed on https://getcomposer.org/doc/05-repositories.md#packages is actually a bit too minimalist in practice.

I would have thought that it would fail over to the contained composer.json but that may not be the case (i.e. perhaps the PackageInterface in https://github.com/composer/composer/blob/master/src/Composer/Autoload/AutoloadGenerator.php is coming from the JSON we're serving up instead). Again, just throwing out ideas without really looking.

Either way, it looks to me like we'll probably have to significantly expand the amount of information we're extracting from composer.json uploads in hosted, and this also has significant implications for group merge as we'll need to handle that there as well (meaning that we cannot just serve up the minimal subset I've been relying on thus far). I'll take a look at that perhaps after the group work has been merged down so as not to have too many clashes with my other branch?

As a note to the interested, we generally try to be very parsimonious in terms of what metadata we store for a particular format's components or assets and only capture those pieces of information that are obviously useful to the user or necessary for the format's implementation. These get stored in our NoSQL database, but for large attribute maps (in terms of keys or in terms of nested content) we sometimes encounter scalability issues, particularly when multiplied across all the components or assets in all the repositories. So that's the reason why we don't just grab everything and store it in there in the first place.

from nexus-repository-composer.

@TheBay0r, how bad it would be for you if I made some breaking changes to the current implementation? (You would likely have to recreate your proxy and hosted repositories as the underlying representation of some of the metadata would no longer be backward-compatible.) If not I can just stick the new stuff side-by-side so it should still work, but that's kind of ugly to do for something that's not even really ready for release yet.

Anyone else reading this should chime in as well. I know we said this was basically pre-alpha quality and it's just a personal project, but I also don't want to break things for people who might be depending on this if I can help it.

(But it would be nice to clean some of this stuff up based on what we're finding here, and I don't think our upgrade framework is going to be something we want to pull into this for several reasons.)

from nexus-repository-composer.

@fjmilens3 At the moment I'm on vacation/moving, so I have a hard time testing the new features. But for our use a breaking change would be alright at the moment. We currently just the proxy actively (which should be fairly easy to recreate) and the hosted repository is just used to push the packages so far. Because of the autoload issue we were not able to use it actively. So I don't see a big effort in recreating the repository types. Especially if your change helps in the long run.

from nexus-repository-composer.

@TheBay0r, no problem on the vacation/moving, I was actually out the past week which is why I took so long responding. My last couple of jobs have actually been as a remote employee so my wife and I travel all over the US with our little dog, so in a sense we're kind of busy "moving" all the time! Enjoy your travels.

When you get some time to test I'm working on a rather major PR at #18 for this that should include some of these missing fields. Rather than storing the information as format attributes I'm just regenerating static provider.json files whenever one of the associated assets changes; it might need further improvement at scale but unless there's a really sneaky concurrency issue in there I suspect it'll work for most people out there once it's finished, assuming that this is actually the root cause of the problem. I still need to tidy it up.

I was also going to ask if you'd like to (or like me to) open a PR to list you as one of our external contributors on the project. You've done an incredible amount of help with testing and sanity-checking my work, and I think your name deserves to be up there too at this point.

from nexus-repository-composer.

Hi which version of Nexus do i need to use to be able to see all change related to composer.lock
I'm using now Nexus version 3.18 and I have the same issue with composer.lock ( autoload, required ...)

from nexus-repository-composer.