plugins folder breaks interface.install

[davidwallis]

the typelookup now fails for newly loaded interfaces as the InterfaceInstall method in PackageManager.cs points to the wrong path

[davidwallis]

that is assuming the plugins folder is new :)

[davidwallis]

looking at it a bit more, the path needs changing, but then it fails to find the files as previously the code got files without the extensions as typically you load the types without the file extension.. so this needs a quick tweak - but I'm not sure on where else you changed stuff..

A hack makes it load :)

        public static Type TypeLookup(string typeName, string assemblyName)
        {
            if (string.IsNullOrWhiteSpace(assemblyName))
            {
                var type = Type.GetType(typeName);
                return type;
            }

            // look for assembly file
            var dir = Path.Combine(Directory.GetCurrentDirectory(), "plugins");
            var filesFound = Directory.GetFiles(Path.Combine(Directory.GetCurrentDirectory(), "plugins") , assemblyName, SearchOption.AllDirectories);
            if (filesFound.Length == 0)
            {
                filesFound = Directory.GetFiles(Directory.GetCurrentDirectory(), assemblyName, SearchOption.TopDirectoryOnly);
            }

            if (filesFound.Length == 0)
            {
                filesFound = Directory.GetFiles(Directory.GetCurrentDirectory(), assemblyName + ".dll", SearchOption.AllDirectories);
            }

            if (filesFound.Length == 0)
            {
                throw new FileNotFoundException($"Couldn't load assembly for interface/type {typeName}", assemblyName);
            }

            foreach (var fileName in filesFound)
            {
                var assembly = Assembly.LoadFrom(fileName);
                var type = assembly.GetType(typeName);
                if (type != null)
                    return type;
            }

            return null;
        }

[Bounz]

Hi, @davidwallis3101. Yes, I know about this problem. I changed the folder name to plugins in advance of preparing to work on #10 (Move all editable files into one folder). Here is my proposal for folder structure of HomeGenie:

installation directory
- bin           - core/backend of HG
- web           - core/frontend part
- data          - settings, statistics database, modules, automation programs
  - programs            - precompiled automation programs
- logs
- plugins       - interfaces, gateways, widgets
  - interfaces
  - gateways
  - widgets
- backups
- tmp

Right now V1.1.16 is not ready for use, I published it only to collect more info about settings restore process. And to make the new folder structure possible a lot of work has to be done.

[davidwallis]

Ok, do you want me to have a look at fixing the interface side of it and refactoring those bits?

Are you merging back to main? - Do you have a branching strategy (at work they say trunk based dev and merge back to main), or should we change appveyor to build branches with pre-release tagged or something and then master as non-pre release?

I made changes from 1.1.16 - but I notice the solution doesn't have the tests in it? is that because you are using rider?

David

[Bounz]

Yes, if you have time - you can start on #10.

About branching strategy. At work, we use some kind of GitFlow workflow (https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow) (adapted a little bit, so we do not have specific develop branch and hotfix branches, only master, version branches and feature branches. In the beginning, I was going to use the same workflow here. But after reading about trunk based development you mentioned (https://trunkbaseddevelopment.com/) I decided to give it a try (one of the goals of this project is to improve ourselves, isn't it?). Let's try trunk based development with short-lived feature branches. I'll create a document on the forum describing branching and versioning strategies.

About Appveyor. I didn't like that we have to commit and push to check build-script changes, that build constantly fails because of error downloading wpkg and absence of full control on version management. And because I know TeamCity very well I installed my own build server and configured it to build PRs and version branches, run tests and create releases on GitHub.

P.S. About tests: maybe you've branched off V1.1.16 before I merged tests there?

[davidwallis]

[quote]About tests: maybe you've branched off V1.1.16 before I merged tests there?[/quote] I think that is probably correct. :)

Which one should I be branching from and then I will try and make a start on fixing the interfaces to start with :)

I did think about downloading wpkg to the github repo and moving all the build into powershell but at that point we would be better switching to psake for the build script, but again another dependency.. So lets just see how teamcity goes (im not fussy - I started with appveyor to try and assist gene getting releases and PR's out quicker, but never happened)

[Bounz]

Well, as we now follow https://trunkbaseddevelopment.com/ you should branch from master =) To make things easier name the branch with the number of GitHub issue, in this case - HGBE-10.

For now, I really believe that docker distribution will be much more convenient than .deb packages because you can encapsulate all dependencies into the docker image and don't spoil the host system with things like lirc and so on.

For example, this is how I start TeamCity server, just one command and I don't care to install the right version of Java or something else:

docker run -d --name teamcity-server-instance \
    -v /var/teamcity/data:/data/teamcity_server/datadir \
    -v /var/teamcity/logs:/opt/teamcity/logs \
    -p 8880:8111 jetbrains/teamcity-server

[davidwallis]

I get that docker will be good, I doubt its any use for me when referencing gpio on the rpi.

branch with github issue number makes sense now!! wondered what the convention was!

---

From: Alexander Sidorenko notifications@github.com Sent: Monday, March 19, 2018 8:00:31 PM To: Bounz/HomeGenie-BE Cc: David Wallis; Mention Subject: Re: [Bounz/HomeGenie-BE] plugins folder breaks interface.install (#48)

Well, as we now follow https://trunkbaseddevelopment.com/ you should branch from master =) To make things easier name the branch with the number of GitHub issue, in this case - HGBE-10.

For now, I really believe that docker distribution will be much more convenient than .deb packages because you can encapsulate all dependencies into the docker image and don't spoil the host system with things like lirc and so on.

For example, this is how I start TeamCity server, just one command and I don't care to install the right version of Java or something else:

docker run -d --name teamcity-server-instance \ -v /var/teamcity/data:/data/teamcity_server/datadir \ -v /var/teamcity/logs:/opt/teamcity/logs \ -p 8880:8111 jetbrains/teamcity-server

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHubhttps://github.com/Bounz/HomeGenie-BE/issues/48#issuecomment-374351261, or mute the threadhttps://github.com/notifications/unsubscribe-auth/ANNq_p9tNuZqcB9LqsZ4mDDR6SSKajYiks5tgA5egaJpZM4Ss2oE.

[Bounz]

I doubt its any use for me when referencing gpio on the rpi.

I think it should work with usage of right docker command flags, see https://blog.hypriot.com/post/lets-get-physical/ for example.

[davidwallis]

I believe we can close this now? @Bounz

[Bounz]

I'm testing it right now on my RPi. If everything goes well I'll close this issue =)

[davidwallis]

i can confirm this is working

[Bounz]

Me too.