Split up into two packages or continue with rust+python inside one repository?

[jas4711]

Hi! I am considering packaging this project for Debian since it appears relevant to the Sigstore python software stack as a dependency, and wanted to reach out and see if you have any general concerns about this?

Debian has a Rust team and a Python team, and somewhat different methods for maintaining packages. I can probably get a monolithic package to work, and there are many examples of packages like this already.

I'm curious what your plans are towards getting v1.0 out -- how far away is that release?

Are you likely to make any big changes like splitting the project into one python part and one rust part?

For what it's worth, I support getting v1.0 out as soon as possible to declare some stable APIs for the python consumer space, and worry less about getting the implementation perfect, but I haven't looked into detail of this package and I'm not familiar with the API design either.

For reference, here is the packaging work as it will evolve:
https://salsa.debian.org/python-team/packages/python-rfc3161-client

Thanks,
Simon

[woodruffw]

Hi @jas4711, thank you for reaching out!

and wanted to reach out and see if you have any general concerns about this?

No concerns! This package is designed to be a generic RFC 3161 client but we built it specifically for the Sigstore ecosystem (and sigstore-python especially), so packaging it in that context makes perfect sense.

I'm curious what your plans are towards getting v1.0 out -- how far away is that release?

We should be pretty close to it -- I think the main reason we're holding at beta is because we haven't fully "shaken" our API design assumptions to see if they're sound. However, I'm not especially opposed to declaring a 1.0 with the current public API, since we can always bump to 2.0 🙂 -- CC @DarkaMaul for thoughts.

Are you likely to make any big changes like splitting the project into one python part and one rust part?

Nope, we're likely to keep everything in this one repo! That keeps the development process simple for us.

[DarkaMaul]

Hi @jas4711, thanks a lot for reaching out.

As @woodruffw said, I think we are pretty close from a 1.0 release as the current public API is sufficient for our usage in sigstore-python (which was the initial target of the project).

The only thing I would like to see merged before going to 1.0 is to remove this TODO but that can be addressed before end-of-year.

[jas4711]

Thank you for feedback! I feel encouraged to proceed with packaging as it looks right now, and encourage you to publish v1.0 if indeed people are using the code and you aren't actively doing massive API changes. As said, there is always opportunity for a v2.0 that breaks API. Removing the warning about pre-v1.0 code quality at the top of the README helps too, if the code is actually ready for it of course.

One thing that would make my life easier is if you clarified who is the copyright holder of this work, there are no copyright statements in the source code. There is an Apache-2.0 license statement, but as far as I understand you need to something also say something like:

   Copyright [yyyy] [name of copyright owner]

   Licensed under the Apache License, Version 2.0 (the "License");
   you may not use this file except in compliance with the License.
   You may obtain a copy of the License at

       http://www.apache.org/licenses/LICENSE-2.0

   Unless required by applicable law or agreed to in writing, software
   distributed under the License is distributed on an "AS IS" BASIS,
   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
   See the License for the specific language governing permissions and
   limitations under the License.

I suggest to put this in your README with your current reference to the Apache-2.0 license.

While I proceed with packaging, I may find other issues and I hope to bring them up -- I just started working on packaging, so I'm nowhere finished on this.

/Simon

[woodruffw]

I suggest to put this in your README with your current reference to the Apache-2.0 license.

Sounds good -- I've opened #97 for this.

[woodruffw]

We should be good for a 1.0 here now -- I'll cut it today. Thanks for pushing this forwards @jas4711, and please let us know if there's any questions that come up during packaging!