[GH-ISSUE #550 ] [LGSM] Considuring a move to Python #446

Author

Owner

@ghost commented on GitHub (Dec 14, 2015):

That would be really awesome.

Your project needs a better language to grow. But please, do it in Python 3 =).

By the way, you could apply for an open source license of Pycharm. Your project have all the requirements.

@ghost commented on GitHub (Dec 14, 2015): That would be really awesome. Your project needs a better language to grow. But please, do it in Python 3 =). By the way, you could apply for an open source license of Pycharm. Your project have all the requirements.

kerem commented

Author

Owner

@ScottSmudger commented on GitHub (Dec 14, 2015):

As long as the script is just as easy to use, not many people would care.

The ease-of-us of your current script is why it's so popular.

If you keep that level of simplicity, then the move will be easy.

You could always just start it on another branch anyway, and just accept any contributions through here on Github.

But yes, I have seen how powerful Python is, and the move would definitely provide more benefits. Only 1 downside would be the time it would take.

I can test anything that you may have

@ScottSmudger commented on GitHub (Dec 14, 2015): As long as the script is just as easy to use, not many people would care. The ease-of-us of your current script is why it's so popular. If you keep that level of simplicity, then the move will be easy. You could always just start it on another branch anyway, and just accept any contributions through here on Github. But yes, I have seen how powerful Python is, and the move would definitely provide more benefits. Only 1 downside would be the time it would take. I can test anything that you may have

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 14, 2015):

Ease of use it my number one priority. I don't want to over complicate the scripts. And python 3 makes sense to use :-)

@dgibbs64 commented on GitHub (Dec 14, 2015): Ease of use it my number one priority. I don't want to over complicate the scripts. And python 3 makes sense to use :-)

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 14, 2015):

I am totally for this idea, but just 2 things to keep in mind:

Please, for the love of all things holy, go with Python 3 rather than 2. (if you do this)
Don't forget that you can port parts of the project without porting all of it. For example, it wouldn't hurt to write the functions in Python but possibly leave the individual server scripts as bash. Not necessarily suggesting this (I support an entire overhaul to Python) just something to keep in mind.

@Zer0t3ch commented on GitHub (Dec 14, 2015): I am totally for this idea, but just 2 things to keep in mind: 1. Please, for the love of all things holy, go with Python 3 rather than 2. (if you do this) 2. Don't forget that you can port parts of the project without porting all of it. For example, it wouldn't hurt to write the functions in Python but possibly leave the individual server scripts as bash. Not necessarily suggesting this (I support an entire overhaul to Python) just something to keep in mind.

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 16, 2015):

Anyone recommend good tutorials/resources and tools that can help me learn python? I have installed PyCharm but I need a decent tutorial to get started and get a development environment running.

@dgibbs64 commented on GitHub (Dec 16, 2015): Anyone recommend good tutorials/resources and tools that can help me learn python? I have installed PyCharm but I need a decent tutorial to get started and get a development environment running.

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 16, 2015):

Hi,

I strongly recomend this course: https://www.udemy.com/pythonforbeginnersintro/

For reference, i sometimes go to https://pymotw.com/2/ to pick some examples.

If you need anything regarding python, send me a message and i will be glad to help on the migration process.

@ghost commented on GitHub (Dec 16, 2015): Hi, I strongly recomend this course: https://www.udemy.com/pythonforbeginnersintro/ For reference, i sometimes go to https://pymotw.com/2/ to pick some examples. If you need anything regarding python, send me a message and i will be glad to help on the migration process.

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 16, 2015):

Thanks for this. Once I get going I should be OK. Then I could ask you more specific questions. Currently I need all the basics so I can at least know what im looking at haha. :D

@dgibbs64 commented on GitHub (Dec 16, 2015): Thanks for this. Once I get going I should be OK. Then I could ask you more specific questions. Currently I need all the basics so I can at least know what im looking at haha. :D

kerem commented

http://blog.jetbrains.com/pycharm/files/2010/07/PyCharm_Reference_Card.pdf

Author

Owner

@ghost commented on GitHub (Dec 16, 2015):

No problem :)

One must allways help those who want to learn python.

Also,

print this, and stick it behind your monitor:

http://fossbytes.com/learn-it-faster-the-entire-python-language-in-a-single-image/

@ghost commented on GitHub (Dec 16, 2015): No problem :) One must allways help those who want to learn python. Also, print this, and stick it behind your monitor: http://blog.jetbrains.com/pycharm/files/2010/07/PyCharm_Reference_Card.pdf http://fossbytes.com/learn-it-faster-the-entire-python-language-in-a-single-image/

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 16, 2015):

@dgibbs64 I highly suggest https://www.codecademy.com/ as well. It's less thorough than other materials, but it's great to pop in and out of as references or reminders are needed. I used to do Python all the time, but stopped for a while, and now I visit that site from time-to-time when I need quick refreshers on syntax and whatnot.

@Zer0t3ch commented on GitHub (Dec 16, 2015): @dgibbs64 I highly suggest https://www.codecademy.com/ as well. It's less thorough than other materials, but it's great to pop in and out of as references or reminders are needed. I used to do Python all the time, but stopped for a while, and now I visit that site from time-to-time when I need quick refreshers on syntax and whatnot.

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 16, 2015):

Also, if you do end up doing this Python merge, we could even add an optional GUI in Tk or something similar, on top of the fact that the entire project would become significantly more cross-platform.

On a sidenote, I'm currently thinking of forking and adding another game server, would you be open to merging it once it's done if I somehow manage to do it in Python? (It would be a bit of a bitch to load/call the bash functions you've made, but I could make it work, and it would be a good first step for porting the project over)

@Zer0t3ch commented on GitHub (Dec 16, 2015): Also, if you do end up doing this Python merge, we could even add an optional GUI in Tk or something similar, on top of the fact that the entire project would become significantly more cross-platform. On a sidenote, I'm currently thinking of forking and adding another game server, would you be open to merging it once it's done if I somehow manage to do it in Python? (It would be a bit of a bitch to load/call the bash functions you've made, but I could make it work, and it would be a good first step for porting the project over)

kerem commented

Author

Owner

@lnxprof commented on GitHub (Dec 17, 2015):

I'm a (much) bigger fan of bash than python - use both, curse at only one - so this is a bit of a letdown. Bash scripting was the reason why I initially adopted the lgsm scripts.

The bash root shell is the only hash I've ever smoked.

@lnxprof commented on GitHub (Dec 17, 2015): I'm a (much) bigger fan of bash than python - use both, curse at only one - so this is a bit of a letdown. Bash scripting was the reason why I initially adopted the lgsm scripts. The bash root shell is the only hash I've ever smoked.

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 17, 2015):

@lnxprof Is there anything that bash provides over Python, though? I mean, when it was just a little project, bash made sense. Servers could be quickly and easily thrown together, and it could run on most any machine, bash was practical. But, as the project grows with more and more servers, and even possibly more features, does it not make sense to move to something a bit more "extensible"?

@Zer0t3ch commented on GitHub (Dec 17, 2015): @lnxprof Is there anything that bash provides _over_ Python, though? I mean, when it was just a little project, bash made sense. Servers could be quickly and easily thrown together, and it could run on most any machine, bash was practical. But, as the project grows with more and more servers, and even possibly more features, does it not make sense to move to something a bit more "extensible"?

kerem commented

Author

Owner

@lnxprof commented on GitHub (Dec 18, 2015):

@Zer0t3ch
Absolutely. Let's start with just this one:
90 MB of additional cruft in overhead to deploy python3 - additional add-on libs notwithstanding.
0MB of additional cruft to deploy bash+sed+awk+curl
For disk-limited VPS servers, that's a big hit.

@lnxprof commented on GitHub (Dec 18, 2015): @Zer0t3ch Absolutely. Let's start with just this one: 90 MB of additional cruft in overhead to deploy python3 - additional add-on libs notwithstanding. 0MB of additional cruft to deploy bash+sed+awk+curl For disk-limited VPS servers, that's a big hit.

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 18, 2015):

@lnxprof Fear not!

If you need any help on setting up we can help :)

@ghost commented on GitHub (Dec 18, 2015): @lnxprof Fear not! If you need any help on setting up we can help :)

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 18, 2015):

One idea,

lgsm could be totally revamped by using Flask.

An idea, would be implementing an Admin panel for manage the server , or download servers:

example: https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S

@ghost commented on GitHub (Dec 18, 2015): One idea, lgsm could be totally revamped by using Flask. An idea, would be implementing an Admin panel for manage the server , or download servers: example: https://wrapbootstrap.com/theme/inspinia-responsive-admin-theme-WB0R5L90S

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 18, 2015):

@pereirtc an admin panel is something that is regularly requested however if a web panel was designed I would like it as a optional add-on feature as many users are happy with the simple CLI. My focus will remain as a CLI application (even though I would love a web interface). Once I get the CLI right move on to a web based add-on.

My number 1 focus will always simplicity for the user. Any more complicated features have to be carefully thought about to ensure that its easy for the end user to do. This is why multiple server instance support has been an issue as its not that easy to do simply.

Both @Zer0t3ch and @lnxprof have valid points. My issue currently is that because LGSM has grown to a large project from a few basic scripts, managing and developing has become slower and more cumbersome. I believe that's because BASH scripts are not really designed to be used as a full application as LGSM has become.

I believe the python overhead would be worth the improvements. I should be able to create and the improved speed of development and testing. Should also make my life easier (when I learn it) when developing LGSM.

@dgibbs64 commented on GitHub (Dec 18, 2015): @pereirtc an admin panel is something that is regularly requested however if a web panel was designed I would like it as a optional add-on feature as many users are happy with the simple CLI. My focus will remain as a CLI application (even though I would love a web interface). Once I get the CLI right move on to a web based add-on. My number 1 focus will always simplicity for the user. Any more complicated features have to be carefully thought about to ensure that its easy for the end user to do. This is why multiple server instance support has been an issue as its not that easy to do simply. Both @Zer0t3ch and @lnxprof have valid points. My issue currently is that because LGSM has grown to a large project from a few basic scripts, managing and developing has become slower and more cumbersome. I believe that's because BASH scripts are not really designed to be used as a full application as LGSM has become. I believe the python overhead would be worth the improvements. I should be able to create and the improved speed of development and testing. Should also make my life easier (when I learn it) when developing LGSM.

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 18, 2015):

@dgibbs64 You are right, going to an admin panel would be out of the scope of the project.

Regarding python itself, i'm going to post here some directions about modules wich you should check it out, i believe it will be a direct help for what you seek:

Argument parsing: https://pymotw.com/2/argparse/index.html#module-argparse
Configuration parsing: https://pymotw.com/2/ConfigParser/index.html#module-ConfigParser
Executing OS commands: https://pymotw.com/2/subprocess/index.html#module-subprocess
Http request: http://docs.python-requests.org/en/latest/
Colors :) : https://pypi.python.org/pypi/colorama

Git Integration ( maybe to checkout latest rev of your utility scrips?) : https://github.com/gitpython-developers/GitPython

With that, you can have the base for parsing arguments, use a .ini file to store configurations and most import.

Colors, beautifull colors hehe

@ghost commented on GitHub (Dec 18, 2015): @dgibbs64 You are right, going to an admin panel would be out of the scope of the project. Regarding python itself, i'm going to post here some directions about modules wich you should check it out, i believe it will be a direct help for what you seek: Argument parsing: https://pymotw.com/2/argparse/index.html#module-argparse Configuration parsing: https://pymotw.com/2/ConfigParser/index.html#module-ConfigParser Executing OS commands: https://pymotw.com/2/subprocess/index.html#module-subprocess Http request: http://docs.python-requests.org/en/latest/ Colors :) : https://pypi.python.org/pypi/colorama Git Integration ( maybe to checkout latest rev of your utility scrips?) : https://github.com/gitpython-developers/GitPython With that, you can have the base for parsing arguments, use a .ini file to store configurations and most import. Colors, beautifull colors hehe

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 18, 2015):

thanks @pereirtc thats amaze balls :D. Been watching the tutorial you sent. Very useful so far

@dgibbs64 commented on GitHub (Dec 18, 2015): thanks @pereirtc thats amaze balls :D. Been watching the tutorial you sent. Very useful so far

kerem commented

Author

Owner

@jaredballou commented on GitHub (Dec 26, 2015):

I'm going to play the curmudgeonly old developer here and throw some rain on the parade, but only because I think we may want to consider what we're doing. This is all my opinion based upon being a fairly successful devops guy with some solid success in designing and bringing some pretty big products to market successfully, and my perspective as a user and big fan of this project.

A major no-go red flag for me is Daniel's relative beginner status with Python, seeing as he is the primary developer here, the best time to learn a language isn't during a refactor of an already widely deployed product. At a minimum, I'd start a fresh fork of this and try it out with the mindset that it might not work and be ready to fold it up, but then we run into issues where we're fixing issues in two code bases. Trying to keep a fork in sync in that manner quickly becomes its own undertaking, and might really degrade the ability to keep progress going here.

As a slowly-getting-better Python programmer, I agree that there are features in the language that can make an improvement in development. In particular, there are some ways Python can handle data and functional structures that Bash simply cannot compete with. The question is, do those improvements result in a benefit for the end user, either by way of increased capability or simply a better maintained and more frequently updated product? UX should drive all decisions, if a feature has benefit only for the developers and can't be expressed in terms of a better user experience, it's usually better to skip that work and focus on what the user needs. Even in open source, customer focus should be at the top of the list.

However, my opinion is that the tooling should always follow the needs of design, not the other way around. We define a roadmap, determine needs and requirements, and select a tool for each phase based upon those needs mixed with our own expertise levels. To turn the issue on its head, you say that the testing and ability to solicit contributions is behind the change. So, rather than look simply at Python, let us consider each of those points in a vacuum, and see what the better option is.

In regards to testing, my experience in helping build development teams over the past 10 years is that testing is testing, and it is all about mindset and desire to build correctly rather than quickly. There are tools to help make testing easier, there are tools to help catch you when you don't build proper code, and there are tools to help QA find out problems before release, but they all require a lot of smarts to implement and still require a testing mindset. For smaller projects like this, a lot of times the developers themselves write the tests, which may result in testing that either doesn't match real-world usage, or simply tests the parts of the code the developer already considers important. Point being, when one writes one's own tests, it usually tests the "best" of the work in the first place, seeing as it is the focus of the developer's attention.

So, my suggestion here is rather than look at a new language, we look at how we test the product. I'd start by reviewing the bugs and issues reported, try to solicit data from end users about what games and platforms they are using, and focus testing on making sure those use cases are the focus of the testing drive. We need to look at testing as a way to ensure the majority of users have no issues, rather than simply trying to nail down every technical defect in the product. Focusing in this way helps foster the attitude that we are working to improve the user's experience with the product, rather than looking at what we ourselves think of as important. I've made this mistake myself many times (and still do to this day), but the more we can look outside and get feedback from users, the easier this becomes.

From there, I'd focus on deciding how we want to actually test. Do we want to build a "testers group" of users who have used the product to help test and validate issues, or do we want to build out an entire testing platform ourselves? That helps us decide the next step, of how we actually want to unit test. Will we use an external tool to perform functional tests, or do we simply create scripts to use the product and then validate the output? From there we get into the most difficult part, namely what combinations of tests we will run, and how to determine when a change in the code should trigger one of the test paths? Testing is never "ready" in the sense that it can never test every single combination, but keeping this sort of progression in mind can help figure out where we want to focus first.

My guess here is that given the relatively small developer team, and the use of the product, a good starting point is better instrumentation of the code and better ability for users to report back. If I were in charge, I'd start adding more information about what the script is doing and put that into a simple log so that users can more accurately determine what is happening, and so that their bug reports contain better information. The key is to make is as absolutely simple as possible for a user to take an issue and get it to us with the most actionable information, so thinking in that manner should give us a good idea of what we'd have to add to make this work.

I'd also focus on a core test case of simply creating a new environment and running through create/use/teardown scenarios of each product on each OS platform as a good first step towards a better test methodology. Testing is unfortunately a discipline which has diminishing returns the more time one invests in it, so we may find 90% of the bugs with this simple setup, and then have to spend orders of magnitude more time nailing down the last 10%. It may never be developer time to user failure efficient, so there will always be tests that simply aren't worth the effort to implement. But my guess is this could be done with about a week and a key for each game, using Vagrant on our own machines, and then we could collaborate on the testing toolchain and build something decent.

All of that said, even if Python does end up being the better option, we then need to factor in all the dependencies and issues attendant with such a move. Users now will need to have Python installed and whatever libraries we need, which increases the stuff users have to do before they run the product. In my experience, the more complex the setup the less likely a user will try the product, so I really don't want to give up the existing simplicity we have. In fact, I'd argue that if we want to improve the product more, we'd look at integrating the prerequisite installation and checks into the tool, so that users would simply need to download and go, as the script finds and fixes dependency issues as a part of pre-flight.

I guess all that text can be TL;DR as "Be careful, make decisions based on the roadmap instead of what is fun". It's boring, but unfortunately success is usually pretty boring.

@jaredballou commented on GitHub (Dec 26, 2015): I'm going to play the curmudgeonly old developer here and throw some rain on the parade, but only because I think we may want to consider what we're doing. This is all my opinion based upon being a fairly successful devops guy with some solid success in designing and bringing some pretty big products to market successfully, and my perspective as a user and big fan of this project. A major no-go red flag for me is Daniel's relative beginner status with Python, seeing as he is the primary developer here, the best time to learn a language isn't during a refactor of an already widely deployed product. At a minimum, I'd start a fresh fork of this and try it out with the mindset that it might not work and be ready to fold it up, but then we run into issues where we're fixing issues in two code bases. Trying to keep a fork in sync in that manner quickly becomes its own undertaking, and might really degrade the ability to keep progress going here. As a slowly-getting-better Python programmer, I agree that there are features in the language that can make an improvement in development. In particular, there are some ways Python can handle data and functional structures that Bash simply cannot compete with. The question is, do those improvements result in a benefit for the end user, either by way of increased capability or simply a better maintained and more frequently updated product? UX should drive all decisions, if a feature has benefit only for the developers and can't be expressed in terms of a better user experience, it's usually better to skip that work and focus on what the user needs. Even in open source, customer focus should be at the top of the list. However, my opinion is that the tooling should always follow the needs of design, not the other way around. We define a roadmap, determine needs and requirements, and select a tool for each phase based upon those needs mixed with our own expertise levels. To turn the issue on its head, you say that the testing and ability to solicit contributions is behind the change. So, rather than look simply at Python, let us consider each of those points in a vacuum, and see what the better option is. In regards to testing, my experience in helping build development teams over the past 10 years is that testing is testing, and it is all about mindset and desire to build correctly rather than quickly. There are tools to help make testing easier, there are tools to help catch you when you don't build proper code, and there are tools to help QA find out problems before release, but they all require a lot of smarts to implement and still require a testing mindset. For smaller projects like this, a lot of times the developers themselves write the tests, which may result in testing that either doesn't match real-world usage, or simply tests the parts of the code the developer already considers important. Point being, when one writes one's own tests, it usually tests the "best" of the work in the first place, seeing as it is the focus of the developer's attention. So, my suggestion here is rather than look at a new language, we look at how we test the product. I'd start by reviewing the bugs and issues reported, try to solicit data from end users about what games and platforms they are using, and focus testing on making sure those use cases are the focus of the testing drive. We need to look at testing as a way to ensure the majority of users have no issues, rather than simply trying to nail down every technical defect in the product. Focusing in this way helps foster the attitude that we are working to improve the user's experience with the product, rather than looking at what we ourselves think of as important. I've made this mistake myself many times (and still do to this day), but the more we can look outside and get feedback from users, the easier this becomes. From there, I'd focus on deciding how we want to actually test. Do we want to build a "testers group" of users who have used the product to help test and validate issues, or do we want to build out an entire testing platform ourselves? That helps us decide the next step, of how we actually want to unit test. Will we use an external tool to perform functional tests, or do we simply create scripts to use the product and then validate the output? From there we get into the most difficult part, namely what combinations of tests we will run, and how to determine when a change in the code should trigger one of the test paths? Testing is never "ready" in the sense that it can never test every single combination, but keeping this sort of progression in mind can help figure out where we want to focus first. My guess here is that given the relatively small developer team, and the use of the product, a good starting point is better instrumentation of the code and better ability for users to report back. If I were in charge, I'd start adding more information about what the script is doing and put that into a simple log so that users can more accurately determine what is happening, and so that their bug reports contain better information. The key is to make is as absolutely simple as possible for a user to take an issue and get it to us with the most actionable information, so thinking in that manner should give us a good idea of what we'd have to add to make this work. I'd also focus on a core test case of simply creating a new environment and running through create/use/teardown scenarios of each product on each OS platform as a good first step towards a better test methodology. Testing is unfortunately a discipline which has diminishing returns the more time one invests in it, so we may find 90% of the bugs with this simple setup, and then have to spend orders of magnitude more time nailing down the last 10%. It may never be developer time to user failure efficient, so there will always be tests that simply aren't worth the effort to implement. But my guess is this could be done with about a week and a key for each game, using Vagrant on our own machines, and then we could collaborate on the testing toolchain and build something decent. All of that said, even if Python does end up being the better option, we then need to factor in all the dependencies and issues attendant with such a move. Users now will need to have Python installed and whatever libraries we need, which increases the stuff users have to do before they run the product. In my experience, the more complex the setup the less likely a user will try the product, so I really don't want to give up the existing simplicity we have. In fact, I'd argue that if we want to improve the product more, we'd look at integrating the prerequisite installation and checks into the tool, so that users would simply need to download and go, as the script finds and fixes dependency issues as a part of pre-flight. I guess all that text can be TL;DR as "Be careful, make decisions based on the roadmap instead of what is fun". It's boring, but unfortunately success is usually pretty boring.

kerem commented

Author

Owner

@ScottSmudger commented on GitHub (Dec 27, 2015):

@jaredballou Agreed, maybe it's best to keep the Python port in a separate branch. Continue development for the current bash scripts until @dgibbs64 has the required Python experience for a full conversion or if another experience Python developer helps out.
I don't believe it's worth replacing what currently works. A select amount of people will be able to help you out with testing your python ports, me included.

@ScottSmudger commented on GitHub (Dec 27, 2015): @jaredballou Agreed, maybe it's best to keep the Python port in a separate branch. Continue development for the current bash scripts until @dgibbs64 has the required Python experience for a full conversion or if another experience Python developer helps out. I don't believe it's worth replacing what currently works. A select amount of people will be able to help you out with testing your python ports, me included.

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 27, 2015):

The python version should definitely be in it's own branch, though I don't think it needs to be a complete fork of this project into another. This doesn't even have anything to do with the change in language, it's just common practice to differentiate between stable and development versions via branches.

In the coming weeks, I'm going to attempt to become more acquainted with the current code base, namely understanding all of the functions, and will fork a version for myself and submit some pull requests.

Also, it wouldn't hurt to have a third branch as well. I'm thinking something like this:

Stable - exclusively bash, basically "legacy" so without additional features, but will continue to receive bug patches
Development - exclusively python. This will be built from the ground up with nothing but python. Will likely be unusable for end-users for a while.
Mixed - both python and bash. Maybe be a direct branch from the current bash code base, but maybe each time a function is added to the python branch, it could be transferred to this branch to be used by the existing bash scripts. Hypothetically, this branch would maintain usability (though instable) while simultaneously being able to take advantage of new features as they present themselves

Anyway, that's just my 2¢, curious to know what the dev thinks.

@Zer0t3ch commented on GitHub (Dec 27, 2015): The python version should definitely be in it's own branch, though I don't think it needs to be a complete fork of this project into another. This doesn't even have anything to do with the change in language, it's just common practice to differentiate between stable and development versions via branches. In the coming weeks, I'm going to attempt to become more acquainted with the current code base, namely understanding all of the functions, and will fork a version for myself and submit some pull requests. Also, it wouldn't hurt to have a third branch as well. I'm thinking something like this: 1. Stable - exclusively bash, basically "legacy" so without additional features, but will continue to receive bug patches 2. Development - exclusively python. This will be built from the ground up with nothing but python. Will likely be unusable for end-users for a while. 3. Mixed - both python and bash. Maybe be a direct branch from the current bash code base, but maybe each time a function is added to the python branch, it could be transferred to this branch to be used by the existing bash scripts. Hypothetically, this branch would maintain usability (though instable) while simultaneously being able to take advantage of new features as they present themselves Anyway, that's just my 2¢, curious to know what the dev thinks.

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 27, 2015):

Wow im getting some awesome feedback and recommendations. This is very handy as I still have lots to learn. There are no immediate Python plans currently. My currents thoughts are to slowly transition as needed and any merges to master I will have to be confident about.

Currently my biggest frustration is lack of time to develop this project as much as I like due to family and work commitments. So anything to optimise my limited time is helpful.

@jaredballou I have only skimmed over your post however I can tell that it is going to be very helpful to me. When I get a spare 15 mins I will have a proper read. Thank you very much for your detailed in-site as a "curmudgeonly old developer"

@dgibbs64 commented on GitHub (Dec 27, 2015): Wow im getting some awesome feedback and recommendations. This is very handy as I still have lots to learn. There are no immediate Python plans currently. My currents thoughts are to slowly transition as needed and any merges to master I will have to be confident about. Currently my biggest frustration is lack of time to develop this project as much as I like due to family and work commitments. So anything to optimise my limited time is helpful. @jaredballou I have only skimmed over your post however I can tell that it is going to be very helpful to me. When I get a spare 15 mins I will have a proper read. Thank you very much for your detailed in-site as a "curmudgeonly old developer"

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 27, 2015):

@jaredballou can you send me your steamid?. me@danielgibbs.co.uk Thanks

@dgibbs64 commented on GitHub (Dec 27, 2015): @jaredballou can you send me your steamid?. me@danielgibbs.co.uk Thanks

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Dec 27, 2015):

By the way, an additional idea I just thought of: using Python, you might be able to cut out some odd dependencies like tmux.

@Zer0t3ch commented on GitHub (Dec 27, 2015): By the way, an additional idea I just thought of: using Python, you _might_ be able to cut out some odd dependencies like tmux.

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 27, 2015):

@jaredballou You are 100% right

@ghost commented on GitHub (Dec 27, 2015): @jaredballou You are 100% right

kerem commented

Author

Owner

@ghost commented on GitHub (Dec 27, 2015):

@dgibbs64 Daniel, mind if add you on steam so we can start kicking this project up? =)

@ghost commented on GitHub (Dec 27, 2015): @dgibbs64 Daniel, mind if add you on steam so we can start kicking this project up? =)

kerem commented

Author

Owner

@nicktimko commented on GitHub (Dec 27, 2015):

I'd be willing to help with a Python port; it's my daily language! I'm less familiar with running game servers though, I just started monkeying around with a UT server and found this project.

Fabric is a nice Python package for remote sys-admining that could be of use, but the developer is fairly obstinate about Python 3. There is a Python 3 fork, and hopefully by the time LGSM+Python leaves beta, Fabric root will support Py3.

Steam me at steamcommunity.com/id/timko

@nicktimko commented on GitHub (Dec 27, 2015): I'd be willing to help with a Python port; it's my daily language! I'm less familiar with running game servers though, I just started monkeying around with a UT server and found this project. Fabric is a nice Python package for remote sys-admining that could be of use, but the developer is fairly obstinate about Python 3. There is a Python 3 fork, and hopefully by the time LGSM+Python leaves beta, Fabric root will support Py3. Steam me at steamcommunity.com/id/timko

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Dec 27, 2015):

@jaredballou That was a good read and given me lots to think about. My focus is definitely on UX and I have spent hours on things like wording and error messages. Its more important to me to ensure that LGSM is simple and easy to use as possible. Since when I started the project I wanted to be able to quickly install game servers on Linux servers.

If moving code to Python compromises on UX I wont implement it. Any move to Python must enhance the UX and reduce the chance of issues. I do want to stress that major changes like this will be a slow cook and may not be implemented at all.

The project has now grown and taken a form I never thought it would and its now moved to the next level. So tools for better testing and allowing improved user feedback is what is required.

With testing in mind I have automated testing from Jenkins CI which has been very useful already at identifying bugs. I would like to be able to use this a little more but am limited by the serverfiles being too large.

I have also just implemented a new hidden option called ./csgoserver dev-debug. This creates a log called dev-debug.log and uses the set command. This already has been extremely useful for me.

I am seeing more people contributing code for me as well which is great. However it another new area to get used to and deal with merges and forks more.

A lot to think about and I will be taking my time with this and being very careful as LGSM is already a great project and I do not want to mess that up.

@dgibbs64 commented on GitHub (Dec 27, 2015): @jaredballou That was a good read and given me lots to think about. My focus is definitely on UX and I have spent hours on things like wording and error messages. Its more important to me to ensure that LGSM is simple and easy to use as possible. Since when I started the project I wanted to be able to quickly install game servers on Linux servers. If moving code to Python compromises on UX I wont implement it. Any move to Python must enhance the UX and reduce the chance of issues. I do want to stress that major changes like this will be a slow cook and may not be implemented at all. The project has now grown and taken a form I never thought it would and its now moved to the next level. So tools for better testing and allowing improved user feedback is what is required. With testing in mind I have automated testing from Jenkins CI which has been very useful already at identifying bugs. I would like to be able to use this a little more but am limited by the serverfiles being too large. I have also just implemented a new hidden option called ./csgoserver dev-debug. This creates a log called dev-debug.log and uses the set command. This already has been extremely useful for me. I am seeing more people contributing code for me as well which is great. However it another new area to get used to and deal with merges and forks more. A lot to think about and I will be taking my time with this and being very careful as LGSM is already a great project and I do not want to mess that up.

kerem commented

Author

Owner

@UltimateByte commented on GitHub (Dec 30, 2015):

Very nice propositions guys, and i hope many of yoy are really motivated for python !
BTW, any way that the python script could be a unique script that could DL the chosen gameserver after chosing it from a list ? Maybe a step closer from being a linux packet ?

@UltimateByte commented on GitHub (Dec 30, 2015): Very nice propositions guys, and i hope many of yoy are really motivated for python ! BTW, any way that the python script could be a unique script that could DL the chosen gameserver after chosing it from a list ? Maybe a step closer from being a linux packet ?

kerem commented

Author

Owner

@jaredballou commented on GitHub (Jan 6, 2016):

If you need test machines, I can probably hook you up. I have a few Xen hosts here with about 18TB of storage, the upload connection isn't super fast but for testing it works fine. Or, if you just need disks, I have a few 1TB drives collecting dust I can send your way.

@jaredballou commented on GitHub (Jan 6, 2016): If you need test machines, I can probably hook you up. I have a few Xen hosts here with about 18TB of storage, the upload connection isn't super fast but for testing it works fine. Or, if you just need disks, I have a few 1TB drives collecting dust I can send your way.

kerem commented

Author

Owner

@UltimateByte commented on GitHub (Jan 6, 2016):

I'm personally considering using one of those for my tests :
https://www.pulseheberg.com/vps/simple
Or maybe just use a VM, as i got a 100mbit/s connexion at home already, which isn't that bad. :)

@UltimateByte commented on GitHub (Jan 6, 2016): I'm personally considering using one of those for my tests : https://www.pulseheberg.com/vps/simple Or maybe just use a VM, as i got a 100mbit/s connexion at home already, which isn't that bad. :)

kerem commented

Author

Owner

@ghost commented on GitHub (Jan 6, 2016):

@dgibbs64

Just for curiosity, any date plans?

@ghost commented on GitHub (Jan 6, 2016): @dgibbs64 Just for curiosity, any date plans?

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Jan 6, 2016):

Not currently. Im very overwhelmed currently and dont have much time. So this will take a long time.

@dgibbs64 commented on GitHub (Jan 6, 2016): Not currently. Im very overwhelmed currently and dont have much time. So this will take a long time.

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Jan 6, 2016):

@UltimateByte @dgibbs64 When it comes to testing, you guys might consider Vultr, as they charge by the hour. You can set up script for cloning and testing, and it would be pretty easy to cheaply:

Deploy a new VM
Clone a git branch w/ testing script
Execute the testing script
Delete the VM

That is, unless you want something like a CI that's always running. In that case, I've personally found Kimsufi to be pretty good as far as prices go. (And they have servers in many countries)

@Zer0t3ch commented on GitHub (Jan 6, 2016): @UltimateByte @dgibbs64 When it comes to testing, you guys might consider [Vultr](https://www.vultr.com/), as they charge by the hour. You can set up script for cloning and testing, and it would be pretty easy to cheaply: 1. Deploy a new VM 2. Clone a git branch w/ testing script 3. Execute the testing script 4. Delete the VM That is, unless you want something like a CI that's always running. In that case, I've personally found Kimsufi to be pretty good as far as prices go. (And they have servers in many countries)

kerem commented

Author

Owner

@JimTR commented on GitHub (Jan 6, 2016):

Late at the party but perhaps use php as the wrapper ? this allows you to exec any script bash/python and display the output ... this then allows some command line options that could be used either web or command line so terminal php -f somefile.php 'command' works the same as http://domain.com/somefile.php?'command' ... I guess python does the same but I have never played with it

@JimTR commented on GitHub (Jan 6, 2016): Late at the party but perhaps use php as the wrapper ? this allows you to exec any script bash/python and display the output ... this then allows some command line options that could be used either web or command line so terminal php -f somefile.php 'command' works the same as http://domain.com/somefile.php?'command' ... I guess python does the same but I have never played with it

kerem commented

Author

Owner

@UltimateByte commented on GitHub (Jan 6, 2016):

@Zer0t3ch
Thanks for the advice, i didn't know that one.
There's also online.net's service at 3€/month
https://www.scaleway.com/
Maybe more appropriate as i prefer to keep my server on. :)
@JimTR No worries you're not too late, the move isn't starting now and will take time if it happens !

@UltimateByte commented on GitHub (Jan 6, 2016): @Zer0t3ch Thanks for the advice, i didn't know that one. There's also online.net's service at 3€/month https://www.scaleway.com/ Maybe more appropriate as i prefer to keep my server on. :) @JimTR No worries you're not too late, the move isn't starting now and will take time if it happens !

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Jan 9, 2016):

@JimTR Basically any language can run executables/scripts of another language as long as they're compiled or there is a local interpreter (like for Python)

Though, PHP could serve as a decent potential front-end due to the ease of adding a web interface. That said, you could also add a web interface to Python. (via hosting its own embedded server)

It might be best to just pick one language and roll with it, though. No reason to mix-and-match in the future, just needs to be properly planned out and one superior language to be picked.

@Zer0t3ch commented on GitHub (Jan 9, 2016): @JimTR Basically any language can run executables/scripts of another language as long as they're compiled or there is a local interpreter (like for Python) Though, PHP could serve as a decent potential front-end due to the ease of adding a web interface. That said, you could also add a web interface to Python. (via hosting its own embedded server) It might be best to just pick one language and roll with it, though. No reason to mix-and-match in the future, just needs to be properly planned out and one superior language to be picked.

kerem commented

Author

Owner

@ghost commented on GitHub (Jan 11, 2016):

@Zer0t3ch with Flask there's no need to use php or external programming language dependencies.

@ghost commented on GitHub (Jan 11, 2016): @Zer0t3ch with Flask there's no need to use php or external programming language dependencies.

kerem commented

Author

Owner

@jaredballou commented on GitHub (Jan 12, 2016):

The thing that I worry about in Python, PHP, or anything besides Bash is that we are expanding the prerequisites. Yes, practically every Linux system has both of those, but not all. That means we now have a slightly larger barrier to entry, and we have to test a much wider array of systems. See, Bash scripts are mostly all written for Bash 3, so there isn't as big a deal as Python 2.6/2.7/3.3 or PHP 5.2/5.3/5.4/5.6 being very different from one another. Without stuff like RedHat SCL, most of these can;t be installed side by side, so we would need to be very careful and aware that this sort of move increases the test load significantly.

I'm going to go ahead and say my "final opinion" on this is that we stick with Bash unless we find a compelling reason to switch to another language that can't be reasonably accommodated. We're already pretty far behind the 8 ball with getting the test stuff settled and having time to add new games and features, and my opinion is that we need to prioritize the time we spend on making the tool as solid as we can by prioritizing new games/features the community needs and spending more time addressing bugs.

Now, that said, the web interface and some other points here are a good idea. A nice parallel project of a Web-based front end that deploys LGSM and then configured and installs/manages the games behind it would be a great idea. This would also give us some "positive pressure" to make sure that the commands are well-defined, well-documented, and well-tested, and could be a useful tool to help us do automated testing in and of itself. However, I think that I need to fly my UNIX nerd flag here and say that we ought to do one thing well, and enable other tools to "plug in" and enable some of these more complex features.

@jaredballou commented on GitHub (Jan 12, 2016): The thing that I worry about in Python, PHP, or anything besides Bash is that we are expanding the prerequisites. Yes, practically every Linux system has both of those, but not all. That means we now have a slightly larger barrier to entry, and we have to test a much wider array of systems. See, Bash scripts are mostly all written for Bash 3, so there isn't as big a deal as Python 2.6/2.7/3.3 or PHP 5.2/5.3/5.4/5.6 being very different from one another. Without stuff like RedHat SCL, most of these can;t be installed side by side, so we would need to be very careful and aware that this sort of move increases the test load significantly. I'm going to go ahead and say my "final opinion" on this is that we stick with Bash unless we find a compelling reason to switch to another language that can't be reasonably accommodated. We're already pretty far behind the 8 ball with getting the test stuff settled and having time to add new games and features, and my opinion is that we need to prioritize the time we spend on making the tool as solid as we can by prioritizing new games/features the community needs and spending more time addressing bugs. Now, that said, the web interface and some other points here are a good idea. A nice parallel project of a Web-based front end that deploys LGSM and then configured and installs/manages the games behind it would be a great idea. This would also give us some "positive pressure" to make sure that the commands are well-defined, well-documented, and well-tested, and could be a useful tool to help us do automated testing in and of itself. However, I think that I need to fly my UNIX nerd flag here and say that we ought to do one thing well, and enable other tools to "plug in" and enable some of these more complex features.

kerem commented

Author

Owner

@ScottSmudger commented on GitHub (Jan 12, 2016):

By migrating to Python you are also to a degree supporting windows which could bring a multitude of other problems.

@ScottSmudger commented on GitHub (Jan 12, 2016): By migrating to Python you are also to a degree supporting windows which could bring a multitude of other problems.

kerem commented

Author

Owner

@nicktimko commented on GitHub (Jan 12, 2016):

I can install Bash in Windows (just like I'd have to install Python, as it doesn't come by default), does LGSM currently support Windows to a degree?

@nicktimko commented on GitHub (Jan 12, 2016): I can install Bash in Windows (just like I'd have to install Python, as it doesn't come by default), does LGSM currently support Windows to a degree?

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Jan 21, 2016):

@nicktimko If you have the necessary utils, some servers might work on Windows, but it's unlikely. For example, all of the source servers download and execute Linux-compiled binaries to work. I imagine very few of these servers would work without some kind of Windows compatibility added. That said, it wouldn't be crazy difficult to add, simply another annoying thing to manage.

@ScottSmudger You see potential problems - and you're not wrong - but I see an increased userbase. Put simply, as long as Windows isn't "officially supported" (like we will ignore any Windows-related issues, but will accept any Windows-related merge-request patches) it shouldn't cause any additional problems right off the bat. (i.e. it's not a problem until the dev chooses to recognize it as a compatible platform. Until then it's no different than people running the current bash stuff on Windows machine. Doable but unsupported)

@jaredballou You make some good points, but many of them can be worked around. For now, I'm going to ignore any PHP-related issues as that's only been a small mention, not really the front-and-center of attention right now

installing multiple python implementations is no big deal at all. (At least with my experience in Arch) Any intelligent *nix OS should allow them to be installed side-by-side, symlinking /usr/bin/python2 to the appropriate binary and /usr/bin/python3 to the appropriate binary, as well as /usr/bin/python to the default. As long as we specify which in our shebang (for the uninformed) there shouldn't be an issue. That said, I do recognize the potential for issues when you have someone who just installed Ubuntu to try running a server only to be stopped because they can't install the right version of Python, which is part of why it wouldn't hurt to simply maintain a "legacy" version (this bash version) for simplicity sake.
As far as setting up multiple separate projects as "plug-ins" for one-another, I agree completely. What I don't agree with is developing a bunch of complicated plugins that rely on a bunch of cobbled-together bash to function. It seems archaic and prone to problems, IMHO. Put simply, Bash is just fine for LGSM if it wants to remain a small collection of scripts, but it's not really practical if the entire project is to evolve into something bigger.

And, as an afterthought to that last point, (and some of those others) could it be potentially "better" to just build a platform for server management and allow people to write their own plugins? (mainly for initialization and updating, starting and stopping would mostly be the work of the base platform) This could help with many issues. For example, the cross-platform issue. Someone wants to make a server work on Windows? Fine. The base platform could already be completely platform-independent allowing anyone to simply port a server's plugin for another OS.

@Zer0t3ch commented on GitHub (Jan 21, 2016): @nicktimko If you have the necessary utils, some servers _might_ work on Windows, but it's unlikely. For example, all of the source servers download and execute Linux-compiled binaries to work. I imagine very few of these servers would work without some kind of Windows compatibility added. That said, it wouldn't be crazy difficult to add, simply another annoying thing to manage. ## @ScottSmudger You see potential problems - and you're not wrong - but I see an increased userbase. Put simply, as long as Windows isn't "officially supported" (like we will ignore any Windows-related issues, but will accept any Windows-related merge-request patches) it shouldn't cause any additional problems right off the bat. (i.e. it's not a problem until the dev chooses to recognize it as a compatible platform. Until then it's no different than people running the current bash stuff on Windows machine. Doable but unsupported) ## @jaredballou You make some good points, but many of them can be worked around. For now, I'm going to ignore any PHP-related issues as that's only been a small mention, not really the front-and-center of attention right now - installing multiple python implementations is no big deal at all. (At least with my experience in Arch) Any intelligent *nix OS should allow them to be installed side-by-side, symlinking /usr/bin/python2 to the appropriate binary and /usr/bin/python3 to the appropriate binary, as well as /usr/bin/python to the default. As long as we specify which in our shebang ([for the uninformed](http://www.wikiwand.com/en/Shebang_%28Unix%29)) there shouldn't be an issue. That said, I do recognize the potential for issues when you have someone who just installed Ubuntu to try running a server only to be stopped because they can't install the right version of Python, which is part of why it wouldn't hurt to simply _maintain_ a "legacy" version (this bash version) for simplicity sake. - As far as setting up multiple _separate_ projects as "plug-ins" for one-another, I agree completely. What I don't agree with is developing a bunch of complicated plugins that rely on a bunch of cobbled-together bash to function. It seems archaic and prone to problems, IMHO. Put simply, Bash is just fine for LGSM if it wants to remain a small collection of scripts, but it's not really practical if the entire project is to evolve into something bigger. ## And, as an afterthought to that last point, (and some of those others) could it be potentially "better" to just build a platform for server management and allow people to write their own plugins? (mainly for initialization and updating, starting and stopping would mostly be the work of the base platform) This could help with many issues. For example, the cross-platform issue. Someone wants to make a server work on Windows? Fine. The base platform could already be completely platform-independent allowing anyone to simply port a server's plugin for another OS.

kerem commented

Author

Owner

@UltimateByte commented on GitHub (Jan 21, 2016):

A good friend of mine using python every day, told me that python has a built in bash interpreter.
Could be a good way to make a smooth transition if variables can be shared between bash and python, what do you think about that ? Did somebody try it already ?

@UltimateByte commented on GitHub (Jan 21, 2016): A good friend of mine using python every day, told me that python has a built in bash interpreter. Could be a good way to make a smooth transition if variables can be shared between bash and python, what do you think about that ? Did somebody try it already ?

kerem commented

Author

Owner

@nicktimko commented on GitHub (Jan 21, 2016):

Python has a built in interactive interpreter, but it's not bash itself. It's straightforward to access shell vars (environmental variables) from within Python with os.environ['PATH'] or the like. Punch in python on your shell and you can bang around in it (exit() to quit) or there are some online emulators like https://repl.it/languages/python3

@nicktimko commented on GitHub (Jan 21, 2016): Python has a built in _interactive interpreter_, but it's not bash itself. It's straightforward to access shell vars (environmental variables) from within Python with `os.environ['PATH']` or the like. Punch in `python` on your shell and you can bang around in it (`exit()` to quit) or there are some online emulators like https://repl.it/languages/python3

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Jan 21, 2016):

@UltimateByte Your friend likely meant "bash-like" as in similar to bash as it's interactive, which is true, as @nicktimko said. But like he said, we can still use environment variables, plus you can just call bash scripts via the bash interpreter from python normally, like so:

subprocess.call(["bash", "./script.sh"])

@Zer0t3ch commented on GitHub (Jan 21, 2016): @UltimateByte Your friend likely meant "bash-like" as in similar to bash as it's interactive, which is true, as @nicktimko said. But like he said, we can still use environment variables, plus you can just call bash scripts via the bash interpreter from python normally, like so: ``` subprocess.call(["bash", "./script.sh"]) ```

kerem commented

Author

Owner

@jaredballou commented on GitHub (Jan 21, 2016):

First off, I just want to say that supporting Windows is way beyond the scope of what I am interested in working on, but if others want to work on it I'd be glad to see it. My thinking is Windows is so radically different that it'd probably be better to have a separate PowerShell wgsm script that can interpret the gamedata files and provide at least the core subset of what lgsm does. The fact that Windows paths and permissions are different, the executables and support libraries are different, the service/daemon model being completely different and all the other assumptions in lgsm that it will run on Linux will be a tall order to factor in, and would dilute and complicate the main tool. But if we have enough Windows people, I think moving all the game and action-specific code into descriptive files that lgsm and wgsm digest and execute would be a neat idea.

@Zer0t3ch I agree with pretty much everything you said. My personal belief is that the more dependencies we need, the more difficult it is to set up, we have people who submit bugs for not installing the yum packages needed to support the script, if we have to have them start installing Python, Pip, and all the modules, it's going to get messy. I think a Bash bootstrapper that pulls down Python libraries, checks dependencies, and installs the lgsm-ng core as a "installation process" would help with this a lot, ideally I want to get to the point where I give people a one-liner to download and execute a single script which will walk them through the process start to finish. I've started teasing at this in my fork, but I think if we can do that right then moving to Python might not be unreasonable.

My lgsm-core script has a built-in installer function that deploys itself, I've been looking at dependencies and other "snowflake" items like Source games needing extra dependency libraries, or something like the SourceMod installer I created. The inflexibility of the original tool is becoming a bit of a wall for me, so I'm certainly interested in pitching in if we want to do a small POC and draft out a design.

As I have been doing my radically refactored fork with a single lsgm-core script and all the game-specific stuff contained in separate gamedata files, I've been thinking more and more along the lines of the second thing you mention. Namely, being able to define a generic version of most of these actions (install, start, stop, monitor, etc) and then allow inheritance and overriding to add game-specific functionality without making an entirely new script and support files to maintain.

This is a Python strength, and I think there is a good case for thinking of the lgsm-ng as a platform that people can write plugins into as you suggested. Frankly, the amount of work needed to maintain a product like this is only going to grow, so the more we can compartmentalize and farm out to people outside the core team the better off we will be.

What other sort of things would we change if we were building it again from scratch? And is there anything else out there that we can build on that does this already, or any framework we'd want to look at using as a platform?

@jaredballou commented on GitHub (Jan 21, 2016): First off, I just want to say that supporting Windows is way beyond the scope of what I am interested in working on, but if others want to work on it I'd be glad to see it. My thinking is Windows is so radically different that it'd probably be better to have a separate PowerShell wgsm script that can interpret the gamedata files and provide at least the core subset of what lgsm does. The fact that Windows paths and permissions are different, the executables and support libraries are different, the service/daemon model being completely different and all the other assumptions in lgsm that it will run on Linux will be a tall order to factor in, and would dilute and complicate the main tool. But if we have enough Windows people, I think moving all the game and action-specific code into descriptive files that lgsm and wgsm digest and execute would be a neat idea. @Zer0t3ch I agree with pretty much everything you said. My personal belief is that the more dependencies we need, the more difficult it is to set up, we have people who submit bugs for not installing the yum packages needed to support the script, if we have to have them start installing Python, Pip, and all the modules, it's going to get messy. I think a Bash bootstrapper that pulls down Python libraries, checks dependencies, and installs the lgsm-ng core as a "installation process" would help with this a lot, ideally I want to get to the point where I give people a one-liner to download and execute a single script which will walk them through the process start to finish. I've started teasing at this in my fork, but I think if we can do that right then moving to Python might not be unreasonable. My lgsm-core script has a built-in installer function that deploys itself, I've been looking at dependencies and other "snowflake" items like Source games needing extra dependency libraries, or something like the SourceMod installer I created. The inflexibility of the original tool is becoming a bit of a wall for me, so I'm certainly interested in pitching in if we want to do a small POC and draft out a design. As I have been doing my radically refactored fork with a single lsgm-core script and all the game-specific stuff contained in separate gamedata files, I've been thinking more and more along the lines of the second thing you mention. Namely, being able to define a generic version of most of these actions (install, start, stop, monitor, etc) and then allow inheritance and overriding to add game-specific functionality without making an entirely new script and support files to maintain. This is a Python strength, and I think there is a good case for thinking of the lgsm-ng as a platform that people can write plugins into as you suggested. Frankly, the amount of work needed to maintain a product like this is only going to grow, so the more we can compartmentalize and farm out to people outside the core team the better off we will be. What other sort of things would we change if we were building it again from scratch? And is there anything else out there that we can build on that does this already, or any framework we'd want to look at using as a platform?

kerem commented

Author

Owner

@Zer0t3ch commented on GitHub (Jan 22, 2016):

@jaredballou I'm all for a bootstrapping script. As long as any error messages are verbose, we should be able to easily have a little FAQ with how to fix anything.

As far as Windows goes, there's two significant hold-ups:

An alternate to screen/tmux that can leave shit running in the background. I don't think this really exists, so we would have to dive into services, which is far from anything we're going to do anytime soon.
Actually making sure that the games provide the valid binaries. With most source-based servers that download from Steam, there wouldn't need to be more than a couple lines changed to make it work. With others that might require manually searching a webpage for download links and running different binaries and all that, it would be a lot harder, but not impossible. That's why I'm in favor of making LGSM into a dynamic "platform" for people to make "plugins" for. Keeping the base platform cross-platform would be very easy and people could just make platform-specific plugins.

@Zer0t3ch commented on GitHub (Jan 22, 2016): @jaredballou I'm all for a bootstrapping script. As long as any error messages are verbose, we should be able to easily have a little FAQ with how to fix anything. As far as Windows goes, there's two significant hold-ups: 1. An alternate to screen/tmux that can leave shit running in the background. I don't think this really exists, so we would have to dive into services, which is far from anything we're going to do anytime soon. 2. Actually making sure that the games provide the valid binaries. With most source-based servers that download from Steam, there wouldn't need to be more than a couple lines changed to make it work. With others that might require manually searching a webpage for download links and running different binaries and all that, it would be a lot harder, but not impossible. That's why I'm in favor of making LGSM into a dynamic "platform" for people to make "plugins" for. Keeping the base platform cross-platform would be very easy and people could just make platform-specific plugins.

kerem commented

https://github.com/GameServerManagers/PythonGSM

Author

Owner

@UltimateByte commented on GitHub (Nov 9, 2016):

@UltimateByte commented on GitHub (Nov 9, 2016): https://github.com/GameServerManagers/PythonGSM

kerem commented

Author

Owner

@braunsonm commented on GitHub (Jan 29, 2017):

@dgibbs64 is this project abandoned?

@braunsonm commented on GitHub (Jan 29, 2017): @dgibbs64 is this project abandoned?

kerem commented

Author

Owner

@dgibbs64 commented on GitHub (Sep 19, 2017):

I have decided remaining with bash is the best course of action as it does the job well and I simply do not have the capacity to restart the entire project from scratch. However that does not prevent anyone else developing something in Pythong

@dgibbs64 commented on GitHub (Sep 19, 2017): I have decided remaining with bash is the best course of action as it does the job well and I simply do not have the capacity to restart the entire project from scratch. However that does not prevent anyone else developing something in Pythong

kerem commented