Directory structure

Discuss API design here.
User avatar
La Muerte
Administrator
Posts: 180
Joined: Sun Jul 15, 2012 1:48 pm
Location: Belgium
Contact:

Postby La Muerte » Fri Sep 06, 2013 2:01 am

Code: Select all

Also the current implemenation only uses a single language file (like es, with en=,de=,whaterver= tags), no en/de/whatever subdirectories. As such, you'll have a single language file per plugin, or in rare cases multiple if the plugin uses more then one (internally!).


That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.

I really, really like how SourceMod arranges their language files, specially their dev area for translators. It is genius. http://www.sourcemod.net/translator/?go=translate&op=status
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:04 am

The loadable sub-addons is still not going to happen :P . However, I have been planning adding a built-in system designed to help do that job for plugins. More details on that once I have gotten at least some of that coded.

Satoon
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:06 am

La Muerte wrote:That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.
I much prefer having one translation file over having one for each language...

Satoon
User avatar
La Muerte
Administrator
Posts: 180
Joined: Sun Jul 15, 2012 1:48 pm
Location: Belgium
Contact:

Postby La Muerte » Fri Sep 06, 2013 2:08 am

I do too but only for small projects :)
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:13 am

Trust me, GunGame is not a "small" project, and it works out "much" better having languages set up the way we did in GG51.

Satoon
Omega_K2
Senior Member
Posts: 227
Joined: Sat Jul 07, 2012 3:05 am
Location: Europe
Contact:

Postby Omega_K2 » Fri Sep 06, 2013 2:16 am

La Muerte wrote:That could get ugly when multiple translators try to work for a different language at the same time, one of them will have to start over.

I really, really like how SourceMod arranges their language files, specially their dev area for translators. It is genius. http://www.sourcemod.net/translator/?go=translate&op=status


You can just merge the files if you have 2 different versions (and, if any conflicts occur fix them manually). This is not much of an issue usually. The only problem I can see is getting huge files if many translations are present or trying to keep translations up to date, but you'd need a more elaborate system in place first.
But for modular stuff it still works, see my definelty not final RPG translations:

https://svn.german-slaughterhouse.de/svn/gsrpg/trunk/resource/source-python/translations/gsrpg/
Libraries: k2tools
Plugins (any): GSRPG (soon) | Pretty Status List | MySQLAds (soon)
Plugins (game-specific): None atm

If you happen to find a bug or need help, either post in the release threads or contact me in IRC gamesurge.net:6667 / #sourcepython
User avatar
La Muerte
Administrator
Posts: 180
Joined: Sun Jul 15, 2012 1:48 pm
Location: Belgium
Contact:

Postby La Muerte » Fri Sep 06, 2013 2:18 am

Gungame is a massive project, so you need to wait until one translator is done with the file before another translator of another language can start with it? :eek:

Edit:
You can just merge the files if you have 2 different versions


Ah ok, I didn't think of that :p .
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:21 am

Ummm, no... You can merge changes, just as Omega mentioned in the post above your's. It really isn't that difficult.

Satoon
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:25 am

Also, we broke our language files out so that they were grouped together by what they were for. This looks to be the way Omega has done his in the link he provided. It is a much better way to do things than having one gigantic file.

Satoon
Omega_K2
Senior Member
Posts: 227
Joined: Sat Jul 07, 2012 3:05 am
Location: Europe
Contact:

Postby Omega_K2 » Fri Sep 06, 2013 2:29 am

satoon101 wrote:The loadable sub-addons is still not going to happen :P . However, I have been planning adding a built-in system designed to help do that job for plugins. More details on that once I have gotten at least some of that coded.

Satoon


It's not that hard implement, but overkill if you don't want any extra features, just simple loading of sub-addons. The reason to have such a thing is to get a clear directory structure
Libraries: k2tools

Plugins (any): GSRPG (soon) | Pretty Status List | MySQLAds (soon)

Plugins (game-specific): None atm



If you happen to find a bug or need help, either post in the release threads or contact me in IRC gamesurge.net:6667 / #sourcepython
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:33 am

Yeah, I need this functionality for GunGame anyway, so I already had planned on creating it within SP's API itself. I am trying to work out a way to create a base class that even AddonManager (which will probably be renamed PluginManager here soon) will inherit from.

Satoon
User avatar
La Muerte
Administrator
Posts: 180
Joined: Sun Jul 15, 2012 1:48 pm
Location: Belgium
Contact:

Postby La Muerte » Fri Sep 06, 2013 2:42 am

ok, languages thing I fully agree with now :)

as for site_packages, why not just put under engines again? and also, please add sqlite3 in there as well if it isn't anywhere else yet :o
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 2:45 am

sqlite3 comes with Python, so we don't really need to "add" it. mysql, on the other hand, does not. We might consider adding that at some point, but so far, we have only added site-packages that we are actually "using" with the API.

Satoon
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Fri Sep 06, 2013 4:03 am

Ok, having thought a little more about it, I am liking the following structure:

  • addons/source-python/
    • bin/
      • core binaries
    • data/
      • custom/ - data for custom packages
      • plugins/ - data location for plugins
      • source-python/ - data for SP's Python API
    • packages/
      • custom/ - custom packages created by SP scripters
      • source-python/ - SP's Python API
    • plugins/
      • user made addons to be loaded by "sp load"
    • python/
      • site-packages


All of the other folders are lower-case, so I think I would want to leave "python" that way as well. I would name it python3, but if we migrate to Python4 (since we have stated we want to keep our Python version at the most up-to-date version), I would hate to completely change the directory name at that time. I am still considering moving site-packages inside of the "packages" directory. However, since Python naturally has site-packages within its core packages, I think it might be best to leave it as-is.

Satoon
Omega_K2
Senior Member
Posts: 227
Joined: Sat Jul 07, 2012 3:05 am
Location: Europe
Contact:

Postby Omega_K2 » Fri Sep 06, 2013 5:13 am

I doubt "python4" is coming anytime soon, unless they are going to change their naming scheme.
Libraries: k2tools

Plugins (any): GSRPG (soon) | Pretty Status List | MySQLAds (soon)

Plugins (game-specific): None atm



If you happen to find a bug or need help, either post in the release threads or contact me in IRC gamesurge.net:6667 / #sourcepython
User avatar
La Muerte
Administrator
Posts: 180
Joined: Sun Jul 15, 2012 1:48 pm
Location: Belgium
Contact:

Postby La Muerte » Fri Sep 06, 2013 9:15 am

isn't "python" looking a bit strange a as a sub-folder of source-python?

addons/source-python/python

you could just put all python files in there, thats what i'd expect when seeing that structure : /

python has a too board meaning in my opinion to really make sense in this context

whats wrong with engines? xD
User avatar
mister-man
Member
Posts: 70
Joined: Wed Aug 29, 2012 7:09 pm
Location: Germany

Postby mister-man » Fri Sep 06, 2013 10:29 am

Good morning after a long night ;)

Languages:
I like to put all languages in one file. So all translation are clearly structured.

Structure:

satoon101 wrote:
  • addons/source-python/
    • bin/
      • core binaries
    • data/
      • custom/ - data for custom packages
      • plugins/ - data location for plugins
      • source-python/ - data for SP's Python API
    • packages/
      • custom/ - custom packages created by SP scripters
      • source-python/ - SP's Python API
    • plugins/
      • user made addons to be loaded by "sp load"
    • python/
      • site-packages


I thng it's a good way to structure the folder.
But is one folder with all data not enough? Further a default datalocation (take a look on sm) for plugins without its own datastructure would be nice.

Subscripts:
I have no idea of it works, but at these time I use for subscript importing these code:

Code: Select all

# Import all submudules
__import__ = ['player']
LoadLib = loadlib.loadlib()

def loadPlugins():
    for mod in __import__:
        LoadLib.aodLoad(mod)


Code: Select all

# =============================================================================
# >> IMPORTS
# =============================================================================
import imp


# =============================================================================
# >> CLASSES
# =============================================================================

class loadlib(object):
    def __init__(self):
        self.__loadL = []
       
    def __del__(self):
        pass
       
    def aodLoad(self, item):
        # Format aodloader output
        print('Try to load: ' + item)
        path = 'AoD' + '/' + '_plugins' + '/' + item + '.py'
        importstr = 'AoD' + '.' + '_plugins'  + '.' + item
        print('    Load: ' + path)
        print('    Import: ' + importstr)
        # Load plugin
        try:
            # import .py file
            exec('from AoD._plugins import ' + item)
            self.__loadL.append(item)
        except Exception as e:
            # Print loading error
            print("    Load error: ", e)
        # Exec load section
        try:
           
            exec(item + '.load()')
        except:
            print('    ' + item + ': No load section found')
           
    def aodUnload(self, item):
        pass
       
    def aodList(self):
        pass


But I have no idea of it works, and I thing there a better way. I'm rally new at SP and it would easier for new script authors to have a build in subscript system!
----------

Community of Gamers --> http://c-o-g.de
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Sat Sep 07, 2013 12:29 am

We are starting to get a bit off-topic with the sub-addon discussion, but I have to comment a bit on your code.

First, do not use __import__ as a variable. __import__ is already a built-in function in Python. You actually should be using either __import__ or importlib to load the sub-addons, and NOT exec. I have programmed quite a bit in Python over the last several years, and I can honestly say I have never used "exec". Not saying it doesn't have its place, but it should definitely not be used in this context.
http://docs.python.org/3/library/functions.html#__import__
http://docs.python.org/3.4/library/importlib.html



As far as data folders, I much prefer separating types of data from each other. Having one folder "could" cause folder name duplication. For instance, what if a custom package has data that it wants to put in a "player" directory. Then, we also have a "player" directory already in the "data" folder for the SP Python API. The files will get mixed in together, and that is not a good idea to me. I have always believed in proper separation of ideas and I don't think that will ever change.

Onto other posts. As far as why not "engines", the only place I have seen the default Python packages in a folder with that name is EventScripts. engines does not really describe, to me, what the folder actually houses. I guess, you are right, Omega, that Python 4 is probably further off than this project would need to concern itself with. Python3 or python3 would definitely describe what is in the folder, properly. I think capitalizing it will separate it from the other folders.

Satoon
User avatar
satoon101
Project Leader
Posts: 2698
Joined: Sat Jul 07, 2012 1:59 am

Postby satoon101 » Tue Sep 10, 2013 10:14 pm

I have started work on this locally. I will probably make these changes when we move to GitHub. Adding/removing as many files as we are going to be doing (moving adds new ones and deletes old ones) always causes us to need multiple commits/pushes. I'm not sure if this is a limitation of Mercurial, TortoiseHg, or GoogleCode (I assume GoogleCode, but have never really tested), but I have been told it is not an issue with Git Bash and GitHub.

The structure I am currently working towards:

  • addons/source-python/
    • bin/ - core binaries
    • data/
      • custom/ - data for custom packages
      • plugins/ - data location for plugins
      • source-python/ - data for SP's Python API
    • packages/
      • custom/ - custom packages created by SP scripters
      • site-packages/ - 3rd party packages
      • source-python/ - SP's Python API
    • plugins/ - user made addons to be loaded by "sp load"
    • Python3/ - the Python installation itself


Satoon

Return to “API Design”

Who is online

Users browsing this forum: No registered users and 6 guests