Complete the transition

[Changaco]

From aspen to aspen-core.

[chadwhitacre]

rename package to aspen-core
rename module to aspen_core

I find it annoying when the PyPI name doesn't match the module name (e.g., py.test vs. pytest—I don't even remember which is which as I write). Can we standardize? Options I see:

• aspen_core for both
• aspen.core for both, using package namespaces to overlay with aspen

[Changaco]

It's pretty standard for package names to use hyphens instead underscores, and the hyphen version matches the name of the git repository, but I'm fine with switching if you want.

I considered a package namespace, but in aspen-core's case I think it would only add complexity without providing benefits.

[chadwhitacre]

@pjz at AspenWeb/salon#2 (comment):

So, reading this diff, I really don't like the module name of 'aspen_core'. Why not just 'aspen' ? And make the aspen.py be 'aspen_web' ?

[chadwhitacre]

Why not just 'aspen'?

Because, per AspenWeb/salon#2, "Aspen" is the name of the standalone web framework, and "Aspen Core" is the library that Aspen shares with Flask-Aspen and django-aspen.

[chadwhitacre]

@pjz How about aspen and aspen.core for the package names? Like so ...

	Aspen	Aspen Core
repo	aspen.py	aspen.core.py
module	aspen	aspen.core
PyPI	aspen	aspen.core
RtD	aspen-py	aspen-core-py

[pjz]

I don't really like the idea of shoving everything but the web framework bits into a submodule - it gives the native aspen webserver a priority over other webframeworks that I don't think should exist; why not shove the web framework bits into a submodule or shim like django-aspen and flask-aspen are? native-aspen or wsgi-aspen or something?

[chadwhitacre]

why not shove the web framework bits into a submodule or shim like django-aspen and flask-aspen are?

Because Flask is not shoved into Flask-Aspen, nor Django into django-aspen. To keep that parallelism, we'd need something like an Aspen-Aspen.

[chadwhitacre]

Aspen isn't a web framework that already exists independently of Aspen Core. Aspen depends essentially on Aspen Core. It has no other dispatch mechanism, whereas Flask and Django do.

[chadwhitacre]

This is what I'm seeing:

[chadwhitacre]

it gives the native aspen webserver a priority over other webframeworks that I don't think should exist

Well, @Changaco having pulled us back from the brink on AspenWeb/pando.py#526, we do remain, in fact, a web framework. ;-) Our survival/marketing strategy involves also publishing shims for the two dominant Python frameworks, and that's why it still makes sense to factor out a core library.

We almost became this:

But we didn't.

[pjz]

...and this is where the disagreement lies. I think aspen is the core bit. If Changaco wants to make some web framework based on the old aspen codebase, it should be named something_else: 'birch' maybe. And then there can be birch-aspen. Or maybe reverse it. We rename aspen-core to 'birch' and end up with 'flask-birch' and 'django-birch' and 'aspen-birch'. But IMO having a 'favored' webserver is a path to being ignored by non-favored ones.

[pjz]

Also: the reasons for the split are not marketing-related: they're technical-maintenance related. If Changaco wants to spend his time maintaining a full web framework, well, that's his perogative. But Chad, you and I had, I thought, agreed that trying to maintain request/response objects and all that goes with them was 1) not our core competency and 2) taking so much time that actual aspen features were suffering. No?

[chadwhitacre]

But Chad, you and I had, I thought, agreed that trying to maintain request/response objects and all that goes with them was 1) not our core competency and 2) taking so much time that actual aspen features were suffering.

This is true. What changed is that @Changaco then volunteered to maintain Aspen as a web framework. It's not (it doesn't need to be) just you and me anymore, @pjz. Seems like the two things to sort out are the branding and the org structure.

• Do both exist under a single GitHub org?
• Which brand is which?

Since the web framework @Changaco has volunteered to maintain (aka Aspen 0.42) depends so closely on the Core piece, and also because of the historical connection between the two, I think it makes sense to have both under the same GitHub org. Eh?

But IMO having a 'favored' webserver is a path to being ignored by non-favored ones.

How about "Pando" (cf. AspenWeb/salon#1 (comment), https://github.com/AspenWeb/aspen.py/issues/547#issuecomment-184882756) for the standalone web framework? Is a different brand sufficient to break the "favored" status?

	Aspen	Flask Aspen	Django Aspen	Pando
repo	aspen.py	Flask-Aspen	django-aspen	pando
module	aspen	flask_aspen	django_aspen	pando
PyPI	aspen	Flask-Aspen	django-aspen	pando
RtD	aspen-py	flask-aspen	django-aspen	pando
homepage	http://aspen.io/	http://aspen.io/flask	http://aspen.io/django	http://aspen.io/pando

[chadwhitacre]

I guess I want Aspen 0.42 ~= Pando to exist, and I appreciate that @Changaco has stepped forward to make that possible. I think it's natural to keep a connection between Aspen and Pando, because of Pando's heavy dependence on Aspen, and the historical connection between the two. If Pando withers we can cut it out of the AspenWeb org at that point, or if it gains traction we can spin it out on its own. I don't think there's a compelling reason to make @Changaco spin Pando out into another new org right now. That would just be another month of running around in circles. ;-)

[chadwhitacre]

@pjz We should let @Changaco into our little boat. :-) ⛵

[pjz]

I'm okay with pando in the same org, but yes, I think a rename to something non-'aspen' would make the split more clear. And Pando has made the decision to make Aspen a non-optional part of it, so a pando-aspen isn't needed.

[Changaco]

sigh We've already discussed this, and although it is of course still possible to change, I'd rather not waste time on it.

Splitting aspen into aspen.py and aspen-core.py was not my original proposal, as I wanted to avoid having exactly this discussion, but the fact is that aspen-core.py is the new project here (a library that can be used to create web frameworks and plugins for existing frameworks), not aspen.py (a web framework that has existed for years), so the current naming makes sense.

[Changaco]

@whit537 Do you want me to change the package name to match the module name?

[pjz]

I feel like I'm getting in the way here, so I'll just not do that.

[chadwhitacre]

For context: @pjz just reached out to me via text message, and we ended up having a private phone call. With the move back towards maintaining a full web framework after all, he has decided to step away from the Aspen project.

Thank you for all you've done for Aspen over the years, @pjz. A quick git log --author=pj shows that you've been around since at least April, 2012. We wouldn't be where we are today without you—the dispatcher + test table, Windows portability, content negotiation, release management, monthly calls and backlog maintenance, sprints, etc., etc.. You will be missed, and you are welcome back any time! 👏 👍 🎸 🚀 💃 💯 ⛳

Seriously, thank you. 🙇

[chadwhitacre]

Now, be that as it may, I think @pjz is more or less right, and Pando is the way to go. Yes, Aspen is a web framework that has existed for years ... and it's an also-ran. I believe our shared goal, @Changaco, is for the framework we've been using to continue to exist, so that we can keep using it. The name shouldn't matter to us. The questions should be: how can we best ensure this framework's long-term survival?

Long-term survival for an open-source project means having a vibrant community, but at this point it'd be foolish to keep trying to build a community directly around the framework, because of the dominance of Django and Flask. However, we may be able to build a community around our core library, because it does offer something unique and compelling in the Python web world.

Since Aspen is the brand with at least some equity, I think it makes sense to start with that for the thing we're trying to build a community around: the core library. If we use the Aspen + Pando setup as at #1 (comment), then we can make an http://aspen.io/ that says something like this:

[chadwhitacre]

@Changaco I've reverted dbaa8b306aed1108bac92749f068024cb22fb8bf and made another commit to change the name back in other places. Can you live with this? Merge if so, and I'll proceed to:

 - [ ] rename `aspen.py` to `pando`
 - [ ] rename `aspen-core.py` to `aspen.py`
 - [ ] make a PR to change the name in `pando`
 - [ ] retitle https://github.com/AspenWeb/aspen.py/issues/548 as "port to aspen"

Task list moved to AspenWeb/salon#2 (comment).

[Changaco]

• aspen is not "a filesystem router for Python web frameworks", url-fs-dispatcher.py is supposed to be that. The current aspen-core is simplates + fs-dispatch, and eventually it's supposed to be mostly glue code for simplates.py and url-fs-dispatcher.py.
• I'd rather not have revert commits, let's squash/drop commits.
• 727e4d19be376a02ae336b7da521b2056b7dc8ad needs to be dropped.

[chadwhitacre]

727e4d1 needs to be dropped.

Let's give http://aspen.io/ its own repo.

I'd rather not have revert commits, let's squash/drop commits.

Done. Previous head was a4411d00377d97732e1d3b77ad85c97c5166c2f9.

[chadwhitacre]

Let's give http://aspen.io/ its own repo.

http://github.com/AspenWeb/aspen.io

[chadwhitacre]

Corresponding PR renaming aspen.py to pando is at https://github.com/AspenWeb/aspen.py/pull/552.