Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Package management system #17092

Closed
quentincaffeino opened this issue Feb 27, 2018 · 12 comments
Closed

Package management system #17092

quentincaffeino opened this issue Feb 27, 2018 · 12 comments

Comments

@quentincaffeino
Copy link
Contributor

Hello,

Lately I'm thinking about adding some package management system to godo more often as I move bunch of my libs from project to project.
As I think it would not be that hard to take any of highly used program (such as composer, yarn, pip etc.) and adapting it principles for godot. Also as there's already an asset lib website, it is enough to update it to support keeping packages database.
Also a name have come to my mind: GVen [Gwen], Godot Vendor.

What do you think?

Best 😃

@groud
Copy link
Member

groud commented Feb 28, 2018

Honestly, I don't see the point. The only thing I can see as useful would be the dependency manager.
(having a command-line tool would be useless since we already have the editor)
However, assets are rarely dependent on each other, so for me the asset store is enough. But we could add dependency management to the assets store I guess.

@avril-gh
Copy link
Contributor

We have very nice "asset library" function out there.
you can share your libs, assets, plugins, games, whatever with community or keep it local.

@quentincaffeino
Copy link
Contributor Author

quentincaffeino commented Feb 28, 2018

Firstly also sorry for my "great" English.

having a command-line tool would be useless since we already have the editor

Of course first we should adapt editor for it. But having a cli is also a good option (or even better having it integrated in godot executable so it can be used through parameters)

However, assets are rarely dependent on each other

And that sometimes is a bad thing because you write same pieces of code again and again instead of making maximum profit of code you or someone else wrote before and spending your time on some other more important tasks.

But we could add dependency management to the assets store I guess.

Well yeah, that's the main point. To be able to create and share reusable pieces of code, or "packages".
But it isn't only about adding dependency column to assets db. It requires a bit more work than that.

What I propose is to make a standard. It is required for several reasons:

  1. Any package can be installed via editor or cli using just a package name.
  2. Then any package could install it dependencies along with it using also just package names.
  3. To be able to use each other they need some sort of structure or "namespaces" defined by a standart. And also same structure is used so you can use this packages.

I'm inspired and I personally like composer so I suggest you take a look at it and at packagist.org so you better understand my proposal.

@quentincaffeino quentincaffeino changed the title [Discussion] Package management system Package management system Feb 28, 2018
@avril-gh
Copy link
Contributor

avril-gh commented Mar 1, 2018

(edited due to - its been too long to read)

imho installers, are for people who dont want to go too deeply into something.
Best example could be gamers, They want download game, install and play.
They dont want to know, how it works, why it works, how its made, nor even where its installed.
All they want is play - now.
On oposite side are we developers who must know exacly how something work, where it is and what it do. zip package is perfect here, easy to use, one can look inside, take whats he needed and put where he see it fit. Automated installers apears like a black box.

The same about dependency manager.
First, good modular or OOP code is a module that can be droped into project and it just works.
Less things its dependend on - the better. Ideally could be if its self / core dependent only.
Secondly, managing dependencies by "something" is like striping knowledge from developer who must know and manage project structure by himself, to know it, understand, optimise, expand ect. else one will be lost in own project sooner or later.

@quentincaffeino
Copy link
Contributor Author

There are always two sides of medal. My propose is about adding more structured access to modules on asset store (they still will be on github actually but store will carry some data so it is easy to find those modules). But no one makes you or any body else use it. You can still get zip from github and use it as you want. Same with composer. Composer is just a package manager. How and if you use it is on you. So IMO myBB team haven't thought enough about why do they need composer and what packages do they need.

@avril-gh
Copy link
Contributor

avril-gh commented Mar 1, 2018

I didnt say, yes or no, just sharing thoughts.
What i meant is - Striping from unnecessary mechanical repeatable work seems good, but striping developer from thinking might not be good.

@groud
Copy link
Member

groud commented Mar 1, 2018

What you don't get is that, in video games, there's not a single manner way of doing things.
Basically, when you download some assets on the assets store, you download something that you can modify and adapt to your own needs, while you rarely need something that has a given version and shouldn't be modified. That's why in most cases, having a package manager makes no sense, as in the end, everyone is going to have a modified version of the resource. (Dependencies are going broken if you modify the resource)

The only place this seems to have a meaning is basically for editor or core plugins, which, IMHO, does not need such a complex package manager. Probably something like blender does should be good enough.

@avril-gh
Copy link
Contributor

avril-gh commented Mar 1, 2018

like @groud mentioned "(...) there's not a single manner way of doing things (...)" and i could say the same in my own words "theres as many truths and ways of doing something as count of humans" ...and because of this we begining drifting on a very wide topic here.

Could be sensible if @quentincaffeino would like to introduce to us more detailed draft of his idea, like where he want it to implemented, what options could be available there, and why its good for the most of us, so we could discuss more to the topic.

@vnen
Copy link
Member

vnen commented Mar 1, 2018

I understand the angle to propose this, but game development, as said before, works in a different way. Package managers are common in projects that live a long time and are constantly updated. This kind of software is also usually made by a large team of programmers which come and go, so the setup happens many times during the lifetime of the product.

Games are more like a "one-off" product. You make it, release it, and then forget it. Well, of course you release bugfixes, but updating the dependencies is only made if it's really needed, because it can introduce more bugs. It's also common to have a fixed team that goes in the project from beginning to end, so the setup usually happens only once.

Of course, in the end the community kind of dictates what's available or not. If you decide to make it and everybody starts using it, then we can consider making it official. But for now I don't see a need for an automatized package manager.

@herman-rogers
Copy link

Something that's not said that is fairly obvious is that usually when downloading assets you save them in a folder that is then versioned and stored on git. In my opinion this is pretty bad - you have a massive assets folder that then gets copied across the team and you have the overhead of adding to the mess. Perhaps its easy to manage a small project when its only you (or a game jam). But for a production product this can become really cumbersome.

@elopezga
Copy link

@herman-rogers I agree with this sentiment. There is value in developing assets independently from your project to increase modularity and reusability. Having your assets in separate repos introduces maintainability problems if you simply import them into the project and store them with git, as you mentioned.

In web development, tools such as NPM are very popular because you can include packages into your project without including them in your git repo; you only include the configuration file that tells NPM what packages to include. You benefit from such a system in two ways: everyone in your project automatically has the same dependencies as you (versions and all), and you can easily implement build automation on the cloud. I think having a package manager is great for small projects, and essential for large projects.

The software industry seems to be heading into this type of thinking when dealing with assets. For example, Unity has recently introduced their own package manager to replace their current asset acquisition method. Furthermore, it opens up a platform for people to be able to easily share their assets across projects and with each other. With an abundance of assets to choose from, and the ability to easily import these assets into your project, we can see a massive increase in productivity for our own projects. I believe Godot can greatly benefit from having a package manager.

@Calinou
Copy link
Member

Calinou commented May 26, 2020

Closing in favor of godotengine/godot-proposals#142 and godotengine/godot-proposals#607, as feature proposals are now tracked on the Godot proposals repository.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants