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
{{ message }}
This repository has been archived by the owner on May 13, 2020. It is now read-only.
Let's say that stable first loads bundle.json and then it overrides the json object (dict merge) with the content of bundle.*.json (taken in alphabetical order, the last one has precedence). With this mechanism one can commit bundle.json for their user to use and use local repos while they develop the package.
This can be deactivated by a switch in the stable command line so we are sure that the build passes before a release or a git push to origin.
A further refinement would be a command that updates bundle.json with the versions of the repos defined in bundle.local.json before the release.
I can come up with a PR if the idea sounds good to you.
The text was updated successfully, but these errors were encountered:
I'll have to chew it over a bit. On it's face, I'm not totally opposed to the idea. Although there will be some details to be worked out.
However, I also wonder whether this use case could be served in a way that is simpler and less magic by simply allowing a CLI option to select the bundle file that would be used. For example, a temporary local override workflow could work something like:
cp bundle.json bundle.local.json
vim bundle.local.json # make your edits
stable -b bundle.local.json env ponyc # compile your program
A further refinement would be a command that updates bundle.json with the versions of the repos defined in bundle.local.json before the release.
I'm not really sold on this so far - wouldn't this be as simple as mv bundle.local.json bundle.json?
I do agree on simplicity, my solution was over-complicated and doesn't do more than a simple CLI --bundle option and a simple Makefile would do.
The use case for the bundle generation is: in bundle.local.json you can put local-path deps so you see instantly the changes in the deps reflected in the current package. When you're ready to push your changes, commit and push all the deps.
The script/command would take care to make bundle.json reflect your local environment, i.e. If the dep is a local-path in bundle.local.json and git* in bundle.json then change the sha1/tag/branch in bundle.json to reflect the current state of the local project.
The command may also issue a warning if some local changes in local deps are not comited or pushed.
Maybe it looks over-complex, too, but it's easy to forget to pin a dependence and break other people's builds.
Let's say that stable first loads
bundle.json
and then it overrides the json object (dict merge) with the content ofbundle.*.json
(taken in alphabetical order, the last one has precedence). With this mechanism one can commitbundle.json
for their user to use and use local repos while they develop the package.This can be deactivated by a switch in the stable command line so we are sure that the build passes before a release or a git push to origin.
A further refinement would be a command that updates
bundle.json
with the versions of the repos defined inbundle.local.json
before the release.I can come up with a PR if the idea sounds good to you.
The text was updated successfully, but these errors were encountered: