Open Baklap4 opened 6 years ago
conventions learned, beeing new on the project and getting code feedback:
Question/Ideas about build & run
I hope we agree that one of the main goals of this project is "X-Plat" (Cross Platform)!
Running on Docker (Alpine or Ubuntu, not Nano!) is a good sample for that.
Depending on that, what is the preferred scripting/shell language for us ?
pure ".cmd" probably NOT! we can write ".sh" that can be used in Windows (using Git-Bash, or the new Linux Subsystem in Windows10)
or we can use pwsh
in the meantime pwsh is available (as installer) for all/most of the docker base images (except alpine, but we can hope that this is solved in a few weeks)
Note to my self: we have different places/contexts with different requirements:
The final runtime docker image should be really small and without any additional scripting language/shell ("docker-entry.sh")
Probably we must be prepared to use some CI-Build System. we are dependeing on the capabilities provided there for scripting languages.
most of the newer CI Systems are providing a Docker Container (for build, not for runtime) installing additional Scripting Languages like pwsh inside that Build Container may not be a problem.
@WernerMairl for the docker issue i'd suggest looking over at my pr #59 this will should be using the output provided by the ci and is as small as 60mb if i'm right. Overhead is within the baseimages
"sort and remove" must be avoided, use "remove" only then it is easy....
You can still use "Sort and Remove"! On Visual Studio you just need to enable the option "Text Editor" > "C#" > "Advanced" > "Place 'System' directives first when sorting usings".
Depending on that, what is the preferred scripting/shell language for us ?
Do we need a scripting language? I'd like to avoid making that choice if possible 😄
Probably we must be prepared to use some CI-Build System.
I need to decide between Travis CI and Visual Studio Team Services. This is on my high on my list of things to do.
Do we need a scripting language? I'd like to avoid making that choice if possible 😄
Agree, but in my understanding a file like "travis.yml" behaves like a scripting language:
The underlinig question is: We should use a language that is highly coupled to a product (Travis, VSTS, et. al)? Or we should try to do the core work in a language where we expect that it can be executed in more different environments ..... (sh/bash, pwsh called by VSTS, Travis and custom CI)
for the moment we should do the easist way that is available => full agree, but we should keep in mind a strategy to avoid that vendor/product lock in
We should use a language that is highly coupled to a product (Travis, VSTS, et. al)?
I'm not too worried about coupling so long as developers can get BaGet up and running easily.
I think for now it'd be best to keep it simple, so I'll look into hooking up Travis CI directly. Adding a .travis.yml
file isn't too intrusive and should get us going for a while.
Also travis is pretty well-known in the github community and has some nice integrations with github.
Do you want to request a feature or report a bug?
Feature
What did you expect to see?
A contributing guide which explained me how to participate in this project.
What did you see instead?
I didn't found a contributing guide. However i've found a README.md which tells me how to build/run the project.
Items to be included in the contributing guide