search

catppuccin / latex

✨ Soothing pastel theme for LaTeX
https://www.ctan.org/pkg/catppuccinpalette
MIT License
38 stars 2 forks source link

Investigate uploading to CTAN #1

Closed sgoudham closed 3 weeks ago

sgoudham commented 6 months ago

Description

This is a tracking issue to investigate the process of uploading this library as a package onto CTAN, allowing it to be easily downloadable through distributed CTAN mirrors and popular TeX distributions.

After reading the CTAN - Upload Addendum, it seems like we will need to:

Additional Resources

sgoudham commented 3 months ago

As mentioned on discord, another user has already beaten us to the punch and uploaded a Catppuccin palette library onto CTAN -> https://www.ctan.org/ctan-ann/id/mailman.8896.1716237231.3764.ctan-ann@ctan.org

Hi @atticus-sullivan! As mentioned above, I saw that you have uploaded your own version of the palette. Would you be interested in helping us package the official catppuccin/palette repository to be uploaded to CTAN? I realise that it's a bit of an odd thing to ask so no worries if you don't want to.

I'm a bit worried that CTAN won't allow duplicate libraries as I believe both repositories behave differently but essentially have the same goal. Do you know if we'd be able to still upload our repository? If not, would you be interested in possibly removing yours and helping us package this one?

Not trying to take away from your work but it would be nice if we could get the official catppuccin/palette package into CTAN!

atticus-sullivan commented 3 months ago

Oh, I didn't know there already existed a latex "version" of catppuccin (ok funny thing, both repositories were created approx at the same time ^^).

Tbh this one of my first packages uploaded to ctan so I don't have that much experience at that point as well. But in my experience the people are very friendly.

I can definitely help you in preparing for uploading to ctan. Still both packages nearly do the same. The only differences I see are

While technically both packages could coexist (I see no name clashes until now), we should try to circumvent this because as we both state, essentially they both do the same.

Do you have a plan / an opinion how we should proceed?

Some additional notes:

Changing ownership etc for the ctan package should be possible if required, but maybe we should be careful about uploading a different package under the same name which uses a slightly different API (while I think not many people are using my package, there might be ones still).

Note: For my issues like copyright or ownership of the github repository are not that important at this point.

Also note that there is https://github.com/atticus-sullivan/beamercolorthemeCatppuccin (which is far from being finished especially because I didn't really use it after developing so it's still in alpha). Just to avoid further conflicts in the future.

sgoudham commented 3 months ago

I can definitely help you in preparing for uploading to ctan.

Thank you! It's greatly appreciated.

Do you have a plan / an opinion how we should proceed?

I definitely would like to try and merge both behaviour's if they are deemed worthwhile for a single package to output, if not then we I think it would prefer the behaviour of the existing catppuccin/latex as we had some prior discussion about the design of the package. That being said, I don't have experience with LaTeX library development and I'd defer to @nyxkrage and @walshyb's opinions on that.

Does LaTeX have the concept of notifying users of breaking changes? Something like semver or a noticeboard of some sort? I know you said that not many people may be using it but it would be good to have a way to notify users if the library was merged.

Ultimately, I think it would make sense for the official catppuccin/latex repository to come under the name catppuccinPalette.

atticus-sullivan commented 3 months ago

we had some prior discussion about the design of the package

That's a point which would interest me. Which design choices did you discuss?

merge both behaviours

To make my point clear on that, catppuccinPalette should have all the functionality that catppuccin/latex has with the (almost only) difference that it's (currently) not possible to change the flavor mid-document. But that's something we should be able to add. Apart from that obviously the color names are a bit different and we have different defaults (especially regarding setting the background page color automatically). But I as well gave some thoughts to these decisions (so I'd like to discuss these (but I see you're the wrong person to discuss technical LaTeX questions so we two alone won't get anywhere by our own) if you insist on the catppuccin/latex behavior).

So from my point of view it would be mostly pushing my package (it's already packaged and has a documentation after all) to this repository, keep+adjust the examples+README etc. (I know this sounds a bit extreme and I don't want to be rude but the the packages are still fairly similar).

Does LaTeX have the concept of notifying users of breaking changes? Something like semver or a noticeboard of some sort?

Not one that would really reach all users. Well there is the mailing list on which package updates can be noted (that's already integrated in the publishing process) but not all users (I'd moreover say only a really small percentage of the users) subscribed to that one. I've created an issue in my repo which I intended to use to notify users (which can subscribe to the issue). That is also linked on the ctan page. Still I'm not sure whether we really need breaking changes (I think the only breaking change that we're unclear about until now is changing the text/background color by default when loading the package).

sgoudham commented 3 months ago

That's a point which would interest me. Which design choices did you discuss?

It was actually surrounding the import of colours into the document and the naming of the variables. We settled on the \usepackage[<flavor>]{catppuccin} syntax as we actually didn't think it made much sense for multiple flavours to be imported into the same document. Hence why the variable names are just ctpBlue or ctpPeach. But I suppose we can revisit that with your implementation if you feel strongly about it / think it's trivial and does not impose too much of an extra maintenance burden?

With regards to the "speaking names", I'd prefer them to be in the same syntax as the vars like ctpSuccess and would prefer them to be aliased, if possible, so that you're not repeating the same RGB definitions. Although we hope to remove this as a concern in the future (See #4 for info on why)

So from my point of view it would be mostly pushing my package (it's already packaged and has a documentation after all) to this repository, keep+adjust the examples+README etc. (I know this sounds a bit extreme and I don't want to be rude but the the packages are still fairly similar).

Yeah, I think the way forward now is if you could pull request into catppuccin/latex with the changes you believe to be necessary and we can continue the conversation there about implementation specific details? Then we can eventually get that PR merged and hopefully another PR with the packaging steps / CI/CD workflow to automatically package so that it's maintainer independant.

I really appreciate you taking the time to engage and would not want to dismiss your work!

Still I'm not sure whether we really need breaking changes (I think the only breaking change that we're unclear about until now is changing the text/background color by default when loading the package).

I feel like it makes sense for the background and text colour to be set by default when loading the package? i.e. If I'm importing a colourscheme package, I'd expect some things to be configured/changed by default? But again, happy to discuss this further in a pull request if you feel strongly that it should not be set by default.

atticus-sullivan commented 3 months ago

we actually didn't think it made much sense for multiple flavours to be imported into the same document

Ok my reasoning here was more like why not define them all and just alias the ones of the selected flavor.

think it's trivial and does not impose too much of an extra maintenance burden?

Well we have to define the colors anyhow and it's just defining aliases :shrug:

the naming of the variables

Yes that's also one point we need to discuss. Do you have a strong opinion on that, or is the Cat[<flavor>]<Color> scheme also ok for you? The only thing I though about here was whether to capitalize or not. Looking at the xcolor docs I saw that "additional" colors there all are defined uppercase, so I did so as well.

With regards to the "speaking names", I'd prefer them to be in the same syntax as the vars like ctpSuccess and would prefer them to be aliased

Yes, I currently do this aliasing.

Yeah, I think the way forward now is if you could pull request into catppuccin/latex with the changes you believe to be necessary and we can continue the conversation there about implementation specific details? Then we can eventually get that PR merged and hopefully another PR with the packaging steps / CI/CD workflow to automatically package so that it's maintainer independant.

Ok maybe we're still not on the same page here. Tbh, I would just mostly push my package (which basically already includes the packaging, just do l3build ctan and the zip archive ready for upload is generated).

I feel like it makes sense for the background and text colour to be set by default when loading the package? i.e. If I'm importing a colourscheme package, I'd expect some things to be configured/changed by default?

Well ok that's a different approach. I thought of this package less about styling the whole document in every aspect with catppuccin (which would be fairly hard since there might be other packages defining the color of elements etc) but more of a provider of a colors (hence the name palette since this package first and for all defines the color palette, everything else is just a nice addon).

sgoudham commented 3 months ago

Yes that's also one point we need to discuss. Do you have a strong opinion on that, or is the Cat[] scheme also ok for you?

I'd be in favour of something like Ctp[<flavour>]<Colour> as Ctp is the convention for the abbreviated prefix across our entire organisation.

Ok maybe we're still not on the same page here. Tbh, I would just mostly push my package (which basically already includes the packaging, just do l3build ctan and the zip archive ready for upload is generated).

I still think this repository has useful examples so I'd be looking towards accepting a PR from yourself to bring in some of your package files and "merge" them with this repository so that it looks cohesive and then design a process / pipeline to upload the package underneath catppuccinPalette as we accept the fact that maintainers come and go in the world of open source. We wouldn't want to depend on a publish workflow that can only be carried out by one singular maintainer.

Let me know if you're still interested in this idea of "merging" your code with ours. If not, then both packages will have to simply co-exist in the space and I will need to check with CTAN if they allow "duplicate" libraries in order to upload this repository as a library.

Well ok that's a different approach. I thought of this package less about styling the whole document in every aspect with catppuccin (which would be fairly hard since there might be other packages defining the color of elements etc) but more of a provider of a colors (hence the name palette since this package first and for all defines the color palette, everything else is just a nice addon).

Yeah this is another valid approach, I suppose I wouldn't really mind if it didn't set the background colour but I'd at least make sure that our README included example configuration on how to style the background and text after loading the theme.

atticus-sullivan commented 3 months ago

Let me know if you're still interested in this idea of "merging" your code with ours.

Well I just uploaded the package I'd propose and created a new PR for it.

sgoudham commented 4 weeks ago

I believe this issue can be closed once the official catppuccin account has the ability to publish to the existing catppuccinPalette CTAN package, initially created by @atticus-sullivan.

sgoudham commented 3 weeks ago

Closing as I've been added as an author here https://www.ctan.org/author/goudham which is linked to https://www.ctan.org/home/catppuccin.

I think another issue should be created to track the work for creating a mailing list as per instructions/guidance from the CTAN admins if we want it to truly reflect an organisation. It's still yet to be decided whether we want to proceed with it.