py*-grpcio* @1.41.1_2: don't fetch from git

[cooljeanius (Eric Gallager)]

The various grpcio ports all fetch from git, and that can take a really long time. It would be easier for end users if we could just have a tarball to download instead.

[ryandesign (Ryan Carsten Schmidt)]

The only reason why anyone would set a port to fetch from git is if a tarball were not available...

[cooljeanius (Eric Gallager)]

Replying to ryandesign:

The only reason why anyone would set a port to fetch from git is if a tarball were not available...

There are actually tarballs available, though, under the "releases" tab. For example, here's the most recent one: ​https://github.com/grpc/grpc/releases/tag/v1.42.0

[ryandesign (Ryan Carsten Schmidt)]

There are no source code release tarballs there. "grpc_objective_c_plugin-1.42.0-macos-x86_64.zip" is a precompiled binary which we do not use. If you are referring to the two links "Source code (zip)" and "Source code (tar.gz)", those are automatically generated tarballs, which never contain git submodules. This project uses and requires the presence of submodules. This is one of the primary reasons why a port might fetch from git.

[cooljeanius (Eric Gallager)]

Replying to ryandesign:

There are no source code release tarballs there. "grpc_objective_c_plugin-1.42.0-macos-x86_64.zip" is a precompiled binary which we do not use. If you are referring to the two links "Source code (zip)" and "Source code (tar.gz)", those are automatically generated tarballs, which never contain git submodules. This project uses and requires the presence of submodules. This is one of the primary reasons why a port might fetch from git.

Well ok, so if the port absolutely needs the submodules, aren't there at least some flags that could be passed to git to make the fetching go quicker? Like, I seem to remember that fetching the entire history of a git repository can take awhile, and that there's a flag to skip that...

[ryandesign (Ryan Carsten Schmidt)]

Yes, it can be specified to fetch only the n most recent commits, or something. The inkscape-devel port for example does this by specifying a --depth to git.

[cooljeanius (Eric Gallager)]

This also applies to the plain grpc port, too, btw... can someone add that to the "Port" field?

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

This also applies to the plain grpc port, too, btw... can someone add that to the "Port" field?

Done

[mascguy (Christopher Nielsen)]

AFAIK, fetching from Git is a necessity, given the need to pull in submodules. (Per comment:4.) Closing.

[cooljeanius (Eric Gallager)]

Replying to mascguy:

AFAIK, fetching from Git is a necessity, given the need to pull in submodules. (Per comment:4.) Closing.

Why not at least pass the --depth flag to git, as per comment:6?

[mascguy (Christopher Nielsen)]

Replying to cooljeanius:

Why not at least pass the --depth flag to git, as per comment:6?

Testing locally on my machine, using --depth=1 for the submodules results in negligible performance gains. (A few seconds at most.) The majority of the fetch time relates to grpc itself.

Feel free to test yourself. But not much we can do.

[cooljeanius (Eric Gallager)]

Replying to mascguy:

Replying to cooljeanius:

Why not at least pass the --depth flag to git, as per comment:6?

Testing locally on my machine, using --depth=1 for the submodules results in negligible performance gains. (A few seconds at most.)

I think the few extra seconds would be a worthwhile gain.