That sounds great to me, as with anything it is about finding the things
that interest you the most. I am fine with a naive <home>/.avogadro that
would work on most OSes, if it doesn't exist we would skip, duplicates may
happen. Personally I would then just symlink whatever local files I am
working on into that.
We can come up with some fuller solutions together, it doesn't all need to
be on you.
On Wed, Feb 28, 2018 at 8:27 AM, B Adarsh <badar...@gmail.com> wrote:
> I would certainly love to work on making the plugin system more organised,
> including taking care of priority paths and local development, but I guess
> I might need a little bit more time than what is available, as I was
> wanting to devote a good amount of time for sketching the proposal for the
> actual MD project. So as of now, can I focus on a preliminary fix (as
> mentioned by Dr. Hanwell) on adding extra paths for local development and
> the downloaded directory, and later work on additional fixes if time
> permits?
>
> If yes, is there any definitive path to be set for local development, or
> can I set any sensible path of my choice?
>
> On Tue, Feb 27, 2018 at 10:53 PM, Geoffrey Hutchison <
> geoff.hutchi...@gmail.com> wrote:
>
>> > This operates on systems where someone may install Avogadro, but does
>> not have root/admin. The better solution would be to have a priority search
>> order, and build up a list of unique names. We should support local
>> development of scripts in a .local/avogadro/user/ etc too. The running
>> Avogadro application should never attempt to write to a system directory.
>> …
>> > I would perhaps ignore the download feature as that might be changed,
>> or we could use a JSON file from the download feature to populate a list of
>> updated search paths. That would let the download feature document the
>> relevant directories, and offer something human readable for debugging.
>> This would make the code a little more complex, but I think that is fine.
>>
>>
>> I had not realized that the downloader was leaving revisions in the
>> directory names - that's a bug, which would be a great pull request. :-)
>>
>> The plugin/download features, as you note, do not have conflict
>> resolution code. Mostly that's because as we were writing it, there weren't
>> real issues. We do want to have multiple search paths to support local
>> development, user scripts, and also the plugins from Avogadro installation.
>>
>> Imagine a scenario where we ship with VASP generator version 1.0. The
>> development of that generator can continue on GitHub, and users could
>> download version 1.2, 2.0, etc. without having to download a new Avogadro
>> binary. (Consider places where users don't have admin rights.)
>>
>> Our vision was that downloadable plugins should have their own directory
>> with a plugin.json to identify the key scripts, e.g.
>> .local/avogadro/generators/vasp/*.*
>> .local/avogadro/data/molecules/*.*
>>
>> This is somewhat tangential to my original suggestion, but if you'd like
>> to work on the plugin loading system, that would be welcome - the student
>> who was coding that graduated.
>>
>> -Geoff
>
>
>
>
> --
> Adarsh Balasubramanian
> Fourth year Undergraduate
> Department of Metallurgical and Materials Engineering
> IIT Madras
> Chennai - 600036
>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Avogadro-devel mailing list
Avogadro-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/avogadro-devel
