Request for a new submodule, tools/depinst

Peter Dimov

11 Nov 2016 11 Nov '16

5:02 p.m.

I'd like to request the creation of a new submodule, tools/depinst, that will contain a Python script depinst.py which would, given a module in libs/, install the dependencies needed for running that module's tests. Currently, the .travis.yml files I use enumerate the dependencies manually, which is a bit tiresome: https://github.com/boostorg/function/blob/develop/.travis.yml - git submodule init libs/algorithm - git submodule init libs/align ... - git submodule init libs/type_traits - git submodule init libs/typeof - git submodule init libs/utility - git submodule init libs/winapi - git submodule init tools/build - git submodule update --depth 1 This will be replaced by just - git submodule update --init --depth 1 tools/depinst - git submodule update --init --depth 1 tools/build - python tools/depinst/depinst.py function

Show replies by date

Rene Rivera

11 Nov 11 Nov

5:15 p.m.

On Fri, Nov 11, 2016 at 12:02 PM, Peter Dimov wrote:

...

I'd like to request the creation of a new submodule, tools/depinst, that will contain a Python script depinst.py which would, given a module in libs/, install the dependencies needed for running that module's tests.

Currently, the .travis.yml files I use enumerate the dependencies manually, which is a bit tiresome:

https://github.com/boostorg/function/blob/develop/.travis.yml

- git submodule init libs/algorithm - git submodule init libs/align

...

- git submodule init libs/type_traits - git submodule init libs/typeof - git submodule init libs/utility - git submodule init libs/winapi - git submodule init tools/build - git submodule update --depth 1

This will be replaced by just

- git submodule update --init --depth 1 tools/depinst - git submodule update --init --depth 1 tools/build - python tools/depinst/depinst.py function

It seems like overkill to create yet another repo for one script. Easier would be to add that in the existing regression repo. And the script downloaded with a wget, or equivalent, as needed. I can give you access to the regression repo if that sounds good to you. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Peter Dimov

6:18 p.m.

Rene Rivera wrote:

...

It seems like overkill to create yet another repo for one script.

Yes but... separating necessary Boost parts into independent (non-submodule) repos never felt right to me. IMO regression needs to be a submodule as well. A recursive clone of Boost should give one everything that is needed. And it does make sense to version the regression tools with the rest. wgetting a random version rubs me the wrong way. Test results should be reproducible. In other words, I think that CI/testing should acquire the necessary scripts by git submodule update --init --depth 1 tools/regression instead of by wget.

Rene Rivera

6:26 p.m.

On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

...

Rene Rivera wrote:

It seems like overkill to create yet another repo for one script.

...
Yes but... separating necessary Boost parts into independent (non-submodule) repos never felt right to me. IMO regression needs to be a submodule as well. A recursive clone of Boost should give one everything that is needed.

Needed for what? And by whom?

...

And it does make sense to version the regression tools with the rest.

Why? wgetting a random version rubs me the wrong way. Test results should be

...

reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction? In other words, I think that CI/testing should acquire the necessary

...

scripts by

git submodule update --init --depth 1 tools/regression

instead of by wget.

How would you bootstrap that? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Peter Dimov

7:19 p.m.

Rene Rivera wrote:

...

...
git submodule update --init --depth 1 tools/regression

How would you bootstrap that?

Not sure what you mean. - cd .. - git clone -b $TRAVIS_BRANCH --depth 1 https://github.com/boostorg/boost.git boost-root - cd boost-root - git submodule update --init --depth 1 tools/regression What is the bootstrap problem here? That the above sequence is not part of the script? Why does it need to be?

...

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

Yes, this to me feels like the right thing to do. When you are testing a specific Boost snapshot, it makes sense for the testing tools to also be a part of this snapshot. And there's also the principled objection of not executing unknown unauthenticated scripts retrieved by wget across the internet, although I won't insist on that. :-)

Daniel James

7:31 p.m.

On 11 November 2016 at 19:19, Peter Dimov wrote:

...

- cd .. - git clone -b $TRAVIS_BRANCH --depth 1 https://github.com/boostorg/boost.git boost-root - cd boost-root - git submodule update --init --depth 1 tools/regression

The super project is constantly changing, so that's no more reproducible than downloading a script. It also doesn't work for pull requests and is excessive boilerplate. If you're worrying about a script changing, could download from a version specific URL. Could also pass a git reference to get a specific version of the super project (although I just download a stable release).

Peter Dimov

7:42 p.m.

Daniel James wrote:

...

On 11 November 2016 at 19:19, Peter Dimov wrote:

...
- cd .. - git clone -b $TRAVIS_BRANCH --depth 1 https://github.com/boostorg/boost.git boost-root - cd boost-root - git submodule update --init --depth 1 tools/regression

The super project is constantly changing, so that's no more reproducible than downloading a script.

Yes, you're right about that.

...

It also doesn't work for pull requests and is excessive boilerplate.

It does work for pull requests. See for instance https://github.com/boostorg/serialization/pull/48 But never mind. I withdraw the request. I agree with Rene that a new submodule just for two files is overkill.

Rene Rivera

7:54 p.m.

On Fri, Nov 11, 2016 at 2:42 PM, Peter Dimov wrote:

...

Daniel James wrote:

...
On 11 November 2016 at 19:19, Peter Dimov wrote:

...
- cd .. - git clone -b $TRAVIS_BRANCH --depth 1 >

https://github.com/boostorg/boost.git boost-root

...
- cd boost-root - git submodule update --init --depth 1 tools/regression

The super project is constantly changing, so that's no more reproducible than downloading a script.

Yes, you're right about that.

It also doesn't work for pull requests and is excessive boilerplate.

...
It does work for pull requests. See for instance

https://github.com/boostorg/serialization/pull/48

But never mind. I withdraw the request. I agree with Rene that a new submodule just for two files is overkill.

You know what's funny.. I forgot you have enough permissions to do whatever :-) So many thanks for asking about it first. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Daniel James

8:02 p.m.

On 11 November 2016 at 19:42, Peter Dimov wrote:

...

It does work for pull requests. See for instance

https://github.com/boostorg/serialization/pull/48

Oh okay, sorry, I didn't realise $TRAVIS_BRANCH was the target branch for pull requests. It still doesn't work for other branches though, which would be an issue for me as that's where I rely on travis.

Rene Rivera

8:07 p.m.

On Fri, Nov 11, 2016 at 3:02 PM, Daniel James wrote:

...

On 11 November 2016 at 19:42, Peter Dimov wrote:

...
It does work for pull requests. See for instance

https://github.com/boostorg/serialization/pull/48

Oh okay, sorry, I didn't realise $TRAVIS_BRANCH was the target branch for pull requests. It still doesn't work for other branches though, which would be an issue for me as that's where I rely on travis.

You mean for other clones? If you have your own Travis account you can add the clone to your account and get the same testing run there. HTH. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Daniel James

8:15 p.m.

On 11 November 2016 at 20:07, Rene Rivera wrote:

...

On Fri, Nov 11, 2016 at 3:02 PM, Daniel James wrote:

...
On 11 November 2016 at 19:42, Peter Dimov wrote:

...
It does work for pull requests. See for instance

https://github.com/boostorg/serialization/pull/48

Oh okay, sorry, I didn't realise $TRAVIS_BRANCH was the target branch for pull requests. It still doesn't work for other branches though, which would be an issue for me as that's where I rely on travis.

You mean for other clones? If you have your own Travis account you can add the clone to your account and get the same testing run there.

I was referring to Peter's script which uses $TRAVIS_BRANCH for the super project. In my modules, I just use a stable release, but if I wanted a new version of a dependency, I'd do what Andrey suggested, and use a specific version of the super project (i.e. a tag or a commit's hash) rather than a branch.

Peter Dimov

8:12 p.m.

Daniel James wrote:

...

Oh okay, sorry, I didn't realise $TRAVIS_BRANCH was the target branch for pull requests. It still doesn't work for other branches though, which would be an issue for me as that's where I rely on travis.

You could check if $TRAVIS_BRANCH is one of master and develop and if not, default to one of these for the superproject, I suppose. I only enable Travis for master and develop, so I haven't encountered this problem. I did encounter the pull request problem though. :-)

Rene Rivera

7:38 p.m.

On Fri, Nov 11, 2016 at 2:19 PM, Peter Dimov wrote:

...

Rene Rivera wrote:

git submodule update --init --depth 1 tools/regression

...
...
How would you bootstrap that?

Not sure what you mean.

- cd .. - git clone -b $TRAVIS_BRANCH --depth 1 https://github.com/boostorg/bo ost.git boost-root - cd boost-root - git submodule update --init --depth 1 tools/regression

What is the bootstrap problem here? That the above sequence is not part of the script? Why does it need to be?

Daniel mentioned the same objections I had :-) Hmm.. Are you saying that getting an old version of the regression tools

...

...
that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

Yes, this to me feels like the right thing to do. When you are testing a specific Boost snapshot, it makes sense for the testing tools to also be a part of this snapshot.

The problem is that there's no guarantee that whatever past version you get will work with the currently deployed up to date system. Remember there's more to testing than just the script one uses to run the tests.

...

And there's also the principled objection of not executing unknown unauthenticated scripts retrieved by wget across the internet, although I won't insist on that. :-)

Through a secure connection to a trusted site? If we worry about ti to that extent we have bigger problems since that's equivalent to "git clone" as far as security is concerned ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Andrey Semashev

7:33 p.m.

On 11/11/16 21:26, Rene Rivera wrote:

...

On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

...
wgetting a random version rubs me the wrong way. Test results should be reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

I think that's correct. In my work, I have a number of scripts to build various libraries, some of which are downloaded from git or other SCMs. It is essential that whenever those scripts are run, they use exactly the same source to build the package. This is usually achieved by checking out a particular tag or revision. I think Boost, as a whole, should support this usage. I realize that checking out a particular revision of each git submodule will always work, but since we already use superproject as the synchronization means of different submodules, checking out a revision of superproject should work.

Rene Rivera

7:45 p.m.

On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev wrote:

...

On 11/11/16 21:26, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

wgetting a random version rubs me the wrong way. Test results should be

...
reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

I think that's correct. In my work, I have a number of scripts to build various libraries, some of which are downloaded from git or other SCMs. It is essential that whenever those scripts are run, they use exactly the same source to build the package. This is usually achieved by checking out a particular tag or revision.

See my answer to this in the other response.. But essentially.. Think about what happens when the test infrastructure changes. I think Boost, as a whole, should support this usage. I realize that

...

checking out a particular revision of each git submodule will always work, but since we already use superproject as the synchronization means of different submodules, checking out a revision of superproject should work.

Haha.. That's really funny. The super project gives as much synchronization guarantee as a human passing around pieces of physical paper around the world as he makes changes to them ;-) -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Andrey Semashev

7:53 p.m.

On 11/11/16 22:45, Rene Rivera wrote:

...

On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev wrote:

...
On 11/11/16 21:26, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

wgetting a random version rubs me the wrong way. Test results should be

...
reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

I think that's correct. In my work, I have a number of scripts to build various libraries, some of which are downloaded from git or other SCMs. It is essential that whenever those scripts are run, they use exactly the same source to build the package. This is usually achieved by checking out a particular tag or revision.

See my answer to this in the other response.. But essentially.. Think about what happens when the test infrastructure changes.

Not sure what you mean here.

...

I think Boost, as a whole, should support this usage. I realize that

...
checking out a particular revision of each git submodule will always work, but since we already use superproject as the synchronization means of different submodules, checking out a revision of superproject should work.

Haha.. That's really funny. The super project gives as much synchronization guarantee as a human passing around pieces of physical paper around the world as he makes changes to them ;-)

git checkout boost-1.62.0 git submodule update Am I not guaranteed to have Boost 1.62 after these commands? If not, something is terribly wrong with the release process.

Rene Rivera

8 p.m.

On Fri, Nov 11, 2016 at 2:53 PM, Andrey Semashev wrote:

...

On 11/11/16 22:45, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

On 11/11/16 21:26, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

...
wgetting a random version rubs me the wrong way. Test results should be

...
reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

I think that's correct. In my work, I have a number of scripts to build various libraries, some of which are downloaded from git or other SCMs. It is essential that whenever those scripts are run, they use exactly the same source to build the package. This is usually achieved by checking out a particular tag or revision.

See my answer to this in the other response.. But essentially.. Think about what happens when the test infrastructure changes.

Not sure what you mean here.

One obvious one.. What would happen when someone checks out and old version and the testing infrastructure has change enough that the old version doesn't work any longer? Do we ignore that possibility and fail in some unpredictable way? Do we implement some version checking and fail nicely but prevent "users" from running the scripts? Do we want to support backward version testing of testing infrastructure to ensure the version checking works for all possible past versions against future versions?

...

I think Boost, as a whole, should support this usage. I realize that

...
...
checking out a particular revision of each git submodule will always work, but since we already use superproject as the synchronization means of different submodules, checking out a revision of superproject should work.

Haha.. That's really funny. The super project gives as much synchronization guarantee as a human passing around pieces of physical paper around the world as he makes changes to them ;-)

git checkout boost-1.62.0 git submodule update

Am I not guaranteed to have Boost 1.62 after these commands? If not, something is terribly wrong with the release process.

You are only guaranteed that because *humans* carefully check-pointed that version and verified it with testing. Can't say the same for any other random commit outside of the tagged releases though. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net -- rrivera/acm.org (msn) - grafikrobot/aim,yahoo,skype,efnet,gmail

Andrey Semashev

8:16 p.m.

On 11/11/16 23:00, Rene Rivera wrote:

...

On Fri, Nov 11, 2016 at 2:53 PM, Andrey Semashev wrote:

...
On 11/11/16 22:45, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 2:33 PM, Andrey Semashev < andrey.semashev@gmail.com> wrote:

On 11/11/16 21:26, Rene Rivera wrote:

...
On Fri, Nov 11, 2016 at 1:18 PM, Peter Dimov wrote:

...
wgetting a random version rubs me the wrong way. Test results should be

...
reproducible.

Hmm.. Are you saying that getting an old version of the regression tools that "matches" a particular checkout of the libraries at some point in time should always work and be a measure of reproduction?

I think that's correct. In my work, I have a number of scripts to build various libraries, some of which are downloaded from git or other SCMs. It is essential that whenever those scripts are run, they use exactly the same source to build the package. This is usually achieved by checking out a particular tag or revision.

See my answer to this in the other response.. But essentially.. Think about what happens when the test infrastructure changes.

Not sure what you mean here.

One obvious one.. What would happen when someone checks out and old version and the testing infrastructure has change enough that the old version doesn't work any longer?

Same thing when he does that with libraries - it would probably not work.

...

Do we ignore that possibility and fail in some unpredictable way? Do we implement some version checking and fail nicely but prevent "users" from running the scripts? Do we want to support backward version testing of testing infrastructure to ensure the version checking works for all possible past versions against future versions?

That is up to you, the maintainers of the testing infrastructure. As far as I'm concerned, it can fail horribly. My point is that there should be a reliable way to checkout any Boost release, at any point in future, and that checkout is synchronized (i.e. all components were tested together and testing results were deemed satisfactory) and the same every time.

...

...
I think Boost, as a whole, should support this usage. I realize that

...
...
checking out a particular revision of each git submodule will always work, but since we already use superproject as the synchronization means of different submodules, checking out a revision of superproject should work.

Haha.. That's really funny. The super project gives as much synchronization guarantee as a human passing around pieces of physical paper around the world as he makes changes to them ;-)

git checkout boost-1.62.0 git submodule update

Am I not guaranteed to have Boost 1.62 after these commands? If not, something is terribly wrong with the release process.

You are only guaranteed that because *humans* carefully check-pointed that version and verified it with testing. Can't say the same for any other random commit outside of the tagged releases though.

Having that guaranteed by humans is a downside, for sure, but the important part is that this tag is a synchronization point and it is stable (i.e. doesn't change). I did not verify, but I also assume that the official release archives are built from the sources that correspond to the git tag. Regarding other commits to the superproject, if I'm not mistaken, they are also synchronization points because it is those commits that are tested, not the individual commits in submodules. Whenever I look at the test matrix I see that synchronized state of Boost. Whether that synchronization is predictable or not is not that relevant in this discussion (well, at least as it currently works).

Andrey Semashev

8:23 p.m.

On 11/11/16 23:16, Andrey Semashev wrote:

...

On 11/11/16 23:00, Rene Rivera wrote:

...
One obvious one.. What would happen when someone checks out and old version and the testing infrastructure has change enough that the old version doesn't work any longer?

Same thing when he does that with libraries - it would probably not work.

...
Do we ignore that possibility and fail in some unpredictable way? Do we implement some version checking and fail nicely but prevent "users" from running the scripts? Do we want to support backward version testing of testing infrastructure to ensure the version checking works for all possible past versions against future versions?

That is up to you, the maintainers of the testing infrastructure. As far as I'm concerned, it can fail horribly.

My point is that there should be a reliable way to checkout any Boost release,

I should have said "any Boost version" here, not just release. Potentially, any revision. And it should work the same way it worked when it was tested.

degski

12 Nov 12 Nov

6:35 a.m.

On 11 November 2016 at 22:16, Andrey Semashev wrote:

...

My point is that there should be a reliable way to checkout any Boost release, at any point in future, and that checkout is synchronized (i.e. all components were tested together and testing results were deemed satisfactory) and the same every time.

The *rust* eco-system uses this approach with *cargo*. Although cargo is still in full-fledged development, it works remarkably well, not to say it's great and getting better all the time as improvments are introduced continuously! Each (sub-)library is built with either specific libraries versions (which can obviously change with a new release) or at least a minimum version. The dependency-version(s) are determined by the library maintainer for each library and is therefore fully automatic and transparent. degski

2937

Age (days ago)

2938

Last active (days ago)

List overview

Download

19 comments

5 participants

participants (5)

Andrey Semashev
Daniel James
degski
Peter Dimov
Rene Rivera