You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we have a good way of finding packages: iron:crypto:crypto.ecf will correctly locate the package.
But what would be really great to have is being able to install dependencies of a package. I propose we do that with:
iron install
Without a package install will look for a dependencies section in package.iron. This looks like:
dependencies
base: v >= 18.07
gobo: 4.1 <= v < 5.0
eposix: master
it will then install these things. I.e. for base it verifies the ISE Eiffel compiler is at least 18.07. This may need work though, as you should be able to compile with either gec or ec. So perhaps we should not list the base library this way.
The version numbers should be github tags. If the version is simply a name, it's a github branch.
We could also use the php composer style versions, so then it would read:
Installation then proceeds to create packages like:
~/.iron/gobo/4.1
It writes the installed version to package-lock.iron (package.iron should become a yml file too at some point IMO). This looks something like:
- packages:
- gobo: 4.1
I.e. something that writes the package + installed version.
Once we have this file, we can change the resolver for iron:crypto:crypto.ecf to go through package-lock.iron. I.e. it looks up what version of gobo actually should be used.
Once this all works, we can work on a proper dependency solver, which picks the compatible versions of packages taking all dependencies into account.
The text was updated successfully, but these errors were encountered:
Adding support for versioning is indeed the next big step, and required step.
You mention github tags. I think the version should be handled by the iron repository server (and then declared by the author via the package.iron)
We should be able to upload different versions for the same package, then the dependency resolver will do its jobs to choose the proper version.
I need to check the implication of using a version number in the path such as ~/.iron/gobo/4.1/...
mainly for the integration with EiffelStudio, and at some point with Gobo as well.
To use a yaml syntax instead of specific syntax, I don't really mind.
For the history, we wanted to avoid using xml, or json, to avoid the same discussions we had for the .ecf files (xml vs xace vs lace vs ...eiffel-like-syntax).
For now, the package.iron tries to use a pseudo eiffel-like syntax, similar to the indexing notes. But ok this is not standard.
I guess a yaml would do the job, we just need to build a simple yaml parser.
But how do we handle requiring a dev version of a package? I think the iron server should be optional. One should be able to install packages straight from github, at least as an option.
Currently we have a good way of finding packages:
iron:crypto:crypto.ecf
will correctly locate the package.But what would be really great to have is being able to install dependencies of a package. I propose we do that with:
Without a package install will look for a dependencies section in
package.iron
. This looks like:it will then install these things. I.e. for base it verifies the ISE Eiffel compiler is at least 18.07. This may need work though, as you should be able to compile with either
gec
orec
. So perhaps we should not list the base library this way.The version numbers should be github tags. If the version is simply a name, it's a github branch.
We could also use the php composer style versions, so then it would read:
Installation then proceeds to create packages like:
It writes the installed version to
package-lock.iron
(package.iron
should become a yml file too at some point IMO). This looks something like:I.e. something that writes the package + installed version.
Once we have this file, we can change the resolver for
iron:crypto:crypto.ecf
to go throughpackage-lock.iron
. I.e. it looks up what version of gobo actually should be used.Once this all works, we can work on a proper dependency solver, which picks the compatible versions of packages taking all dependencies into account.
The text was updated successfully, but these errors were encountered: