On Monday, July 24, 2017 at 6:26:54 PM UTC-5, William wrote: > > > On Mon, Jul 24, 2017 at 4:18 PM Travis Scrimshaw <[email protected] > <javascript:>> wrote: > >> Yes, you can. You should create a ticket (possibly more if it makes sense >> to break it into smaller chucks) and push your code there as you work on it >> so people can look at it. >> >> Someone will likely suggest that you should develop it as a separate >> package built on-top of Sage. However, I only see this as a way to be lazy >> with respect to documentation and tests, and it will not get the same >> visibility that it would being included into Sage. If you are developing it >> not based upon Sage library itself and could be a standalone project, then >> you might want to consider that and have it be included as a dependency of >> Sage. >> > > In fact you should seriously consider building code as a separate package > built on top of Sage. See the active discussion at > > https://groups.google.com/forum/m/#!topic/sage-devel/6gO4bzTZfuU > > There is no discussion about why separate packages: only suggestions about doing it without mentioning any of the advantages or disadvantages. Yes, my wording is (heavily) loaded, but I did give an advantage to developing a separate package: you do not have to have the same coding and documentation standards that is required for integration into Sage. However, I do not recall ever seeing another distinct advantage over simply including the code into Sage proper. I will comment more on that thread
> There are of course pros and cons to developing packages that depend on > Sage versus code that is integrated as part of the core Sage library, and > Travis is perhaps not giving you the absolutey most balanced perspective. > Most Sage developers (including me to some extent), don’t really have a > sense of how modern non-monolithic open source software is developed these > days... It’s fine; I’ve definitely not done a good job trying to educate > people, and I’m incredibly grateful to Marc Masdeu, Nicholas (and many > other French devs) for putting hard work into making it through certain > growing pains. Sage is now over 1 million lines of code in the core > library; and that doesn’t include all the packages that are standard parts > of Sage. The Sage core library is also growing recently more quickly than > in last decade, which just means that the release management (of Voker and > others) and structural refactoring work (e.g., cypari2), is more important > than ever. > > I fully agree that breaking more of the core Sage into smaller, manageable chunks that can be *standalone* packages/projects is something we should do. CyPari is a great example of this. However, I do not think we do not have the infrastructure and integration to do anything reasonable to make Sage simply into a binding agent with various 3rd party packages, which is a logical consequence the concept of making packages built ontop of Sage. Isn't the distributed packages part of the reason you initially created Sage, to stop everyone from reimplementing the same code because they did not have a centralized place to look? Best, Travis -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
