Sloeber / arduino-eclipse-plugin

A plugin to make programming the arduino in eclipse easy
https://eclipse.baeyens.it/
419 stars 131 forks source link

How to freeze the libraries versions in Sloeber? #1349

Closed marcelocsi closed 3 years ago

marcelocsi commented 3 years ago

This is a request. When developing code, it is a very good practice to freeze source code and tools in order to replicate to solve issues from the field.

Therefore, how do I freeze the source code and tools or have a list of the libraries versions in a file where this file can be saved with the project and automatically reconfigure the project when a specific version is required?

jantje commented 3 years ago

Therefore, how do I freeze the source code and tools

Like everybody else in the it industry .... make a virtual machine

or have a list of the libraries versions in a file where this file can be saved with the project and automatically reconfigure the project when a specific version is required?

Well .... it is very likely that in a real project you will change the code of some libraries so you can not just "download an reconfigure" unless you make your own library json file referring to your libraries (which can be easily done in sloeber) which implies a whole release approach for the libraries probably independent of your projects.

However Sloeber currently only supports 1 version of a library to be installed in a Sloeber install (Something which may change one day) so storing the library version for the project can currently not be supported as you can have 2 projects in the sloeber install requiring a different version of the same library.

In other words these are the typical questions a "development shop consultant" gets and the only honest answer is "it depends, if you pay me well enough I will look at the details of your situation and figure something out that can work, but don't be surprised if you change something and the whole thing falls apart"

marcelocsi commented 3 years ago

This is obvious that this is for industry, this is where I came from for more than a decade working on embedded coding releasing code for mass production 2M+ units/year, and this is what I am looking for it right now.

Virtual machine? No, thanks. If something crashes on Eclipse on that machine, my work is to rebuild everything once again - this does not seem to be smart and, this is not using versioning control rationally. My goal was to setup something in git with sloeber in a fashion that I can easily recreate a new sandbox from a git tag and recompile my source code (this is ok) with libraries used in that version, which is not ok because libraries from Arduino might have new versions from time to time.

It looks like my answer is no, I can't pay you money but I would certainly pay beers on a bar!

Thank you for your prompt reply as usual.

jantje commented 3 years ago

Virtual machine? No, thanks. If something crashes on Eclipse on that machine, my work is to rebuild everything once again - this does not seem to be smart and, this is not using versioning control rationally.

The idea is that the virtual machine is "the version". You should not update any components on it; so basically nowadays you should not let it connect to the internets. I worked on a project where the virtual machines were checked into the version control tool. As far as I know this is the only way to 100% guarantee (if your version control tool still works and the vm host software can still run the vm) you can rebuild a release "as was" I would not advice to go that way with unsupported open source software (I mean without paying somebody else to take the blame in case it still doesn't work when you need it ;-) ).

As you have been in the it industry and release management you need no explanation what a hell hole distributed software development can be. Making tags over multiple version control repository consistently is not for the faint of heart. Arduino opted for 1 library = 1 repository for the ease of downloading the master from github. That doesn't make version control life easier. For my most professional Sloeber project (Marvin) I work with my own (copies of) libraries https://github.com/jantje/marvinLibraries/tree/master/libraries so I only need to tag 2 (actually 3 and maybe more**) repositories. I have the library repository open in sloeber and added to my private libraries. As my library repositories contain multiple libraries they are no longer compatible with Arduino IDE

** I also do the same with https://github.com/jantje/ArduinoLibraries so that is -out of my head- 3 repositories to tag.

Sometimes -I guess due to the extensive usage of linking- eclipse doesn't notice the changes in the 'marvinLibraries" or "libraries " project so I didn't check them in and have not tagged them properly :-( I've read somewhere that there is an option in eclipse for better detection of changed files but the problem isn't big enough for me to bother (F5 on the libraries project works fine and better detection is probably going to be more cpu cycles)

With all this in place there is the version number of the product (and related libraries) and what if "a library was sneaked in not from my private libraries". I would advice to have a build environment with a sloeber setup in such a way that does not do auto include or import actions automatically.

Version 4.4 will be a great improvement in version control but the intrinsic problems as touched upon above will require a "dedicated workflow" with "reliable third party checks" which is way beyond the scope of Sloeber

It looks like my answer is no, I can't pay you money but I would certainly pay beers on a bar!

I stopped doing that kind of work; so yes you can't pay me :-D. Basically I stopped accepting any kind of payment as I can't handle the pressure any-more (maybe I can't handle people any-more). I'm interested in a drink and a good talk with you but I fear we are not really in each others neighbourhood.

marcelocsi commented 3 years ago

You know what? In my former employer, we have stored everything in the repository. Everything! Like libraries, project specific codes, tools, compilers, everything under one tag. That would have no point in have virtual machine anymore.

That company has several sites across globe and there is a considerable turnover of people, so, the key point was to install the repository tools to create sandboxes, unzip the configured Eclipse with all required plugins preconfigured (you needed to enter only your user id and password) and in few minutes you could grab any version from production and recompile "as it for production". The point here is to rebuild the executable from source, replicate the failure from field and solve it. So, the code was for embedded systems, so even the hash table of source code would match because even a change in the compiler version would mess it up and the code was tracked by some agencies like UL/IEC/VDE (or any other country with standards).

I truly understand your pain about people; sometimes I wanna beat somebody with a dead cat until the caw meows again.

Well, regarding beer, certainly there is no distance to have a good beer! I am planning to do some travel, btw, where are you from? Maybe I can visit your country, learn your culture by drinking good beer.

jantje commented 3 years ago

You know what? In my former employer, we have stored everything in the repository. Everything! Like libraries, project specific codes, tools, compilers, everything under one tag. That would have no point in have virtual machine anymore.

That is untill you can't run the compilers on "modern OS'es". We had problems with legacy build software in the build chain which could only run on a very specific os (that ran end of support/hardware) so we ran these build machines on a vm anyway so taking a step further and put the build vm's in the version control tool came naturally. The problem with this whole thing is .... it never stops. As I hinted on before, once you check in your vm how are you going to guarantee that future vm hosting software is going to support your vm? And do you really care that the version you build today is still build-able in 10 years? I would guestimate about 99% of all software that was out there 10 years ago will need serious work to be rebuild today.

I wanna beat somebody with a dead cat until the caw meows again.

I like cat's. I wouldn't do that to them it would break my hart 😸

Maybe I can visit your country, learn your culture by drinking good beer.

If you like beer and you end up in western Europe; visit a small country Belgium. I'll be there ;-) https://en.wikipedia.org/wiki/Beer_in_Belgium

marcelocsi commented 3 years ago

Embedded compilers runs fine in old machines like Win98 or in newest machines like Windows 10, without any issues. So, no need to use VM but I do relate your pain about the need when using some other languages.

Belgium is my favorite place for beer! I need to explore more, I was at "drei punke Ländern" from Germany side but I need for sure explore more! Let's discuss it in a near future! lol

Thanks a lot for your support.

Kind regards!