Remove user specific information from about.json

[mandeep]

In relation to #2140, this PR removes the writing of user specific information to about.json. I spoke with @kalefranz and @abarto and neither conda nor Anaconda.org uses the metadata from about.json. I wasn't sure if it was safe to remove the about.json file completely so I limited the content to package information.

[bollwyvl]

Ooh, don't know about this. I had done this in my hacky approach, but only because I didn't have anywhere canonical to put it. I don't think it's reasonable to suggest that two versions of conda-build will produce the same output, so at least that would have to be captured... but at that point, might as well specify everything that was available as who knows (yet) what might be needed.

Anyhow, I had been dreaming of a plugin/feature like:

conda-build --export-build-env foo-0.0.0.tar.bz2 > environment.yml

Which would indeed use the about.json specs to make an environment.yml that could be used to provision a build environment. Instead of a local file path, accepting a URL would be wonderful.

Better still would be...

conda-build --reproduce foo-0.0.0_0.tar.bz2

Which would do the same extraction as above, but then...

• build a temporary environment with what it found
• use the temporary conda in it
  • using the embedded recipe, run conda-build
• check the hashes
  • if not the same, and available, use diffoscope against the generated tar.bz2 to report back what changed

The challenging thing in this are the channels. Without a requirements.txt style representation, one can't necessarily guarantee that conda will resolve what is reported there, so it might be better to reduce it down to a requirements.txt or environment.yaml-style representation. And indeed, at the end of the day, the goal is for two packages in two channels to be the same!

The other thing to do with this would be the .buildinfo approach, and have a separate file which captured this information.

One could also imagine checking/generating .sig files and all kinds of other goodies. For example, if a URL is used, having a well-known location, i.e. foo-0.0.0_0.sig could be automatically checked when reproducing. There's really no claim to be satisfied with a separate .buildinfo, but yet it would still be worthwhile to sign.

So at the end of the day, one could imagine a single run of conda-build generating:

foo-0.0.0_0.buildinfo
foo-0.0.0_0.buildinfo.sig
foo-0.0.0_0.tar.bz2.sig
foo-0.0.0_0.tar.bz2

But now we start getting to some pretty deep stuff, as really what one would want is the ability for other people to sign packages, not just the author, such that an organization could demand that their internal build system had reproduced something claimed in public.

[mandeep]

@bollwyvl You bring up some great points! I think having those two commands in conda-build would be awesome. I'll have to discuss this with @msarahan to see if there's a certain way he would want to approach this.

[github-actions]

Hi there, thank you for your contribution!

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this pull request to remain open please:

1. Rebase and verify the changes still work
2. Leave a comment with the current status

NOTE: If this pull request was closed prematurely, please leave a comment.

Thanks!

[github-actions]

Hi there, thank you for your contribution!

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this pull request to remain open please:

1. Rebase and verify the changes still work
2. Leave a comment with the current status

NOTE: If this pull request was closed prematurely, please leave a comment.

Thanks!