Open nickwesselman opened 6 years ago
I'll present the contrarian case, or at least hope to get to the heart of the need :)
Habitat is intended to show how a Helix solution works, how it can be built, how it can be deployed. If someone installs a package, they're not getting much, if any, of that. They're getting a demo site (which could be helpful in a different context), but there are better demo sites out there -- like Habitat Home.
What would the advantage of the package be, if not just "I want to see what Habitat looks like"?
@derekcorreia I tend to agree, but the specific argument here was that if a developer just wants to see how something specific is wired up in Habitat -- e.g. site-unique datasource locations, that it wouldn't be necessary to pull down source and go through the gulp deploy, if we had a package available.
I implemented Sitecore Update Package generation without the need of a package definition file in my fork: https://github.com/jflheureux/Habitat
It uses gulp scripts and Sitecore Courrier to generate the packages. It works without the need for a webroot so it can be run by continuous integration process.
That could be integrated in the Habitat repo with low effort.
Thanks @jflheureux, good to know. The issue is as much maintaining / testing the artifact as it is the generation, but this seems like a good approach.
Is your feature request related to a problem? Please describe. Developers want to be able to quickly install Habitat and reference its items.
Describe the solution you'd like Request from some community members for package-based install.
Additional context Code can be referenced from GitHub without pulling it down, so this would be a quick way to be able to reference items as well.