Petr Schreiber
20-01-2018, 17:56
Hi,
I think it is time to start thinking about package manager for thinBasic.
What is a package?
Package is directory with code files adding functions and user defined types to the language. It may contain dependencies to other packages as well.
Package could be a 3rd party binary module, set of thinBASIC code files adding some functionality (functions, user defined types) or combination of both.
Good example of package would be for example custom GUI library.
What is a package manager?
Package manager is a mechanism allowing you to create, update, delete and re-use code packages.
Creating a package means taking your code and submitting it to central repository, to be used by others.
Updating a package means submitting an update version of already existing package to central package repository. Older versions would be kept.
Deleting package means removing it from the repository - for example once you replace it with better solution.
Re-using packages means being able to download existing packages in order to support your script.
Package specification
Packages could be referenced by their author and name. It would be nice to be able to specify version of the package I am interested in (to ensure consistency), but specification of version via <, >, =<, => should be possible too.
The package specification file could be actually thinBASIC script, to allow flexibility.
Why is this needed?
While we can keep adding new and new modules to thinBASIC installation, it would be nice to keep the basic installation thin. To make it contain just the common modules which have general purpose.
There is for example no point adding integration with OpenCL (GPGPU library) to native thinBASIC installation, but it would be great to make it easy for users to retrieve and use it.
Package managers are something which all the major programming languages already offer - Ruby and Python are the notable mentions for nice implementations.
Ok, Petr, gimme example!
Imagine you are working on application using OpenCL (for number crunching) and GUI library by Rene for user interface.
Instead of downloading the files and bloating your download with these, you could simply add such file to the script:
package source "thinBasic.com"
package get "PetrSchreiber.OpenCL" version "1.0 - 1.*" ' I am interested in any version from 1.x release, do not want anything from 2.x and later, as it could be backwards incompatible
package get "ReneMiner.GUI"
You could "fetch" the dependencies manually, via something like "thinpm fetch" or thinBasic would do it for you automatically during the first execution.
What do we need now?
It would be nice to discuss what the options in the package specification file would be, and we would also need to investigate how to solve the server side of package manager.
Also, I would like to hear your opinion on the whole thing.
I have good experience with this system from Ruby, as the precise version specification can easily resolve dependency hell by having the dependencies versioned. It reduces the initial download size by downloading really just the script and his package specification file.
Further, if multiple scripts use the same dependency, it is placed just on one place and re-used.
Let me know,
Petr
I think it is time to start thinking about package manager for thinBasic.
What is a package?
Package is directory with code files adding functions and user defined types to the language. It may contain dependencies to other packages as well.
Package could be a 3rd party binary module, set of thinBASIC code files adding some functionality (functions, user defined types) or combination of both.
Good example of package would be for example custom GUI library.
What is a package manager?
Package manager is a mechanism allowing you to create, update, delete and re-use code packages.
Creating a package means taking your code and submitting it to central repository, to be used by others.
Updating a package means submitting an update version of already existing package to central package repository. Older versions would be kept.
Deleting package means removing it from the repository - for example once you replace it with better solution.
Re-using packages means being able to download existing packages in order to support your script.
Package specification
Packages could be referenced by their author and name. It would be nice to be able to specify version of the package I am interested in (to ensure consistency), but specification of version via <, >, =<, => should be possible too.
The package specification file could be actually thinBASIC script, to allow flexibility.
Why is this needed?
While we can keep adding new and new modules to thinBASIC installation, it would be nice to keep the basic installation thin. To make it contain just the common modules which have general purpose.
There is for example no point adding integration with OpenCL (GPGPU library) to native thinBASIC installation, but it would be great to make it easy for users to retrieve and use it.
Package managers are something which all the major programming languages already offer - Ruby and Python are the notable mentions for nice implementations.
Ok, Petr, gimme example!
Imagine you are working on application using OpenCL (for number crunching) and GUI library by Rene for user interface.
Instead of downloading the files and bloating your download with these, you could simply add such file to the script:
package source "thinBasic.com"
package get "PetrSchreiber.OpenCL" version "1.0 - 1.*" ' I am interested in any version from 1.x release, do not want anything from 2.x and later, as it could be backwards incompatible
package get "ReneMiner.GUI"
You could "fetch" the dependencies manually, via something like "thinpm fetch" or thinBasic would do it for you automatically during the first execution.
What do we need now?
It would be nice to discuss what the options in the package specification file would be, and we would also need to investigate how to solve the server side of package manager.
Also, I would like to hear your opinion on the whole thing.
I have good experience with this system from Ruby, as the precise version specification can easily resolve dependency hell by having the dependencies versioned. It reduces the initial download size by downloading really just the script and his package specification file.
Further, if multiple scripts use the same dependency, it is placed just on one place and re-used.
Let me know,
Petr