Feature/git lab support

[matthiasheunecke]

Hi, I have added a GitLab support that uses the GitLab API. A base URL can be specified so that different GitLab instances can be specified as source. The authentication with tokens already implemented for GitHub has also been implemented for GitLab.

The package manager is a great idea and therefore I would like to extend it.

Please feel free to contact me with any questions. Best regards, Matthias Heunecke

[Memnarch]

Hi,
Thanks for the contribution. I'm a bit busy with work at the moment, so it might take some time for me to get this reviewed. So don't be confused if it takes a bit^^" (sorry in advance)
Just skimmed over it and noticed, it seems you have created your feature branch based on feature/multisource (wip, not done) and try to merge this back to master. That's why your pull request has so many files. A lot seems to be from the multisource branch.

Another thing is, I'd prefer to not have author specific headers in each file. This project already has multiple contributors and i'd like to keep the actualy source files clean from whoever added to them. Adding a contributors file to the repo with mentions of what they contributed to might be a good idea and something I should add later on if it is desired(which it seems ;) ).

PS: If your feature needs the multisource feature, I'll need to kick myself to get this one polished so we can get all of it back to master.

[matthiasheunecke]

Sorry for the late reply! I know what it's like to be busy because of work.

Yes, my starting point was indeed the feature/multisource branch. This seemed to be the most suitable base, so I started from there.

Not using author-specific headers is not a problem, I just didn't know that. I will change the headers and commit them again.

Can I help in any way with the multisource function? I would find it practical to be able to specify multiple sources in general. What features or tests are still missing here to make this available in the master?

Best regards, Matthias

[Memnarch]

No problem :)
What's mostly missing is finalization. We can specify multiple sources, which is good. However we can not migrate a package from one source to another and need to use manual labour. I'd like to have that in to support sources with (file)indexed directory structures a user/maintainer does not need to care about(though not for initial release).

For this I plan to extend the IDNPackageSource interface with 2 new methods: NewExporter and NewImporter.
These would return a specific implementation of IDNPackageSourceImporter and IDNPackageSourceExporter.
You give it a package and the source it's from and they will do the rest. The exporter would move the package to a directory, as an example in uncompressed directory form and the importer could have a path parameter to import the files from that path into its own system as a new package. Migration between two sources then simply consists of calling the exporter on one and the importer on the other one. While exporters are mandatory to implement, importers are optional. Github for example won't have an importer, but a directory based source would. Therefore the IDNPackageSource interface needs a way to tell the using party if it supports importing. For example a property. Or the functionality for Ex/Import should sit on the IDNPackageProvider. Not sure about that. However, what I'd like to support is FTP based packagessources and depending on the authentication/rights of the specified FTP user, importing is possible.

And commandline. IIRC the commandline does not yet operate on an aggregated source which encapsulates all subsources like the IDE-Extension. And possible additions to the commandline to allow specifying specific sources when installing a package. Though, for times sake, I plan to just let it operate on an aggregated source for the first release.