Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: Git repository package source #9

Open
galaxystar opened this issue Feb 9, 2016 · 2 comments
Open

Feature Request: Git repository package source #9

galaxystar opened this issue Feb 9, 2016 · 2 comments

Comments

@galaxystar
Copy link

I'd really like for Projeny to be able to clone the repos and install the repos as packages as it would for any other package. This would save the time of having to use .unitypackages

As an aside: I'd like to set up my release source as a git repository. Many git repository frameworks (Github, Bitbucket, Gitlab) support REST APIs to facilitate downloading a single file for listing of sources.

@svermeulen
Copy link
Contributor

The focus of this first release was more about managing multiple unity projects once you already have an existing set of local packages. Support for remote packages was kept extremely simple for now which mostly amounts to just local/network folders of unitypackage files. I do think there's a lot of interesting things we could do there but I'm not sure yet the best way to go about it.

One idea would be to add integration with repository managers like Nexus/Nuget/Bower/npm. It seems like it would be a pretty big can of worms to try and do this kind of thing ourselves and these packages already have it figured out so it seems like it would be better to just hook into that.

So maybe you could install plugins to Projeny for each of these different repository managers, that would allow you to download remote packages (with their remote dependencies), and then the plugin would convert these remote packages to a collection of local packages that Projeny could then manage like it does now. Then by storing where the local package was installed from you could do things like upgrades etc. (which would also be handled by the plugin)

I'm open to any thoughts/criticisms/other suggestions on this though

@galaxystar
Copy link
Author

As you mentioned, there are a lot of ways to address package sources. The traditional approaches seem like they would need to be there. Making sure the approach is extendable as possible is key.

I'm coming from the view point of mid-to-large scale development with a lot of shared components where most of the packages would be decentralized and developed in house. Where Projeny is now, and where it looks to be moving forward appears to be focusing primarily on consumers of packages (which is important too) but I'd like it to be well rounded.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants