search

SemanticMediaWiki / SemanticMediaWiki

🔗 Semantic MediaWiki turns MediaWiki into a knowledge management platform with query and export capabilities
https://www.semantic-mediawiki.org
Other
506 stars 225 forks source link

Create SemanticBundle repository #573

Closed mwjames closed 6 years ago

mwjames commented 9 years ago

After explaining again to someone that doing a normal Composer update for a SB based installation is not recommended, I created [0] which when all tests are passed [1, 2] should be transferred to the normal https://github.com/SemanticMediaWiki account.

The SemanticBundle repository will only add packages that can be installed via Composer (and therefore can be assigned a dependency) and deploy unit tests to verify that a component actually works and does not interfere with other packages within the same bundle.

Aside from the issue that classes are now correctly generated (which is the main pain point for people doing a manual update without running auto-dumpload), it can serve as litmus test to confirm that all bundle components are able to work together.

[0] https://github.com/mwjames/SemanticBundle [1] https://gerrit.wikimedia.org/r/#/c/166784/ [2[ https://travis-ci.org/mwjames/SemanticBundle/jobs/38066206

plegault3397 commented 9 years ago

I have been using it without the bundle for so long know I prefer not to us it.

mwjames commented 9 years ago

I have been using it without the bundle for so long know I prefer not to us it.

The reason is to define a dependency matrix and actually run our unit/integration tests for all components that can be bundled together. This is why those packages can only become part of the bundle if Composer is supported and unit tests are provided otherwise having a loose bundle as of now does not guarantee to work or as seen several times in the past, users mix packages and blame SMW-core for being uninstallable.

PS: I don't have time to share in explaining (again and again) that SB (the manual package) and SMW-core are not to be mixed therefore if someone executes composer require mediawiki/semantic-bundle:~2.0 we can be certain that it will work and is tested on Travis-CI for the packages available with that bundle.

mwjames commented 9 years ago

While no official release has been tagged, using composer require mediawiki/semantic-bundle '2.0.*@dev' will [0] pass all tests (thanks @s7eph4n for the swift support) for the components installed:

"mediawiki/semantic-mediawiki": "2.0.*",
"mediawiki/semantic-result-formats": "2.0.*",
"mediawiki/semantic-extra-special-properties": "1.2.*",
"mediawiki/semantic-glossary": "1.1.*,>=1.1.1",
"mediawiki/semantic-maps": "3.1.*"

Most critical for packages that provide tests is the means to confirm the usage of internal SMW functions and hooks to ensure that if something has changed it can be caught during the execution.

Not supported packages are:

[0] https://travis-ci.org/mwjames/SemanticBundle/builds/38085387

JeroenDeDauw commented 9 years ago

Semantic Forms is actually installable via composer now. You could use my fork for over half a year already, but a few days ago the composer.json file actually got merged into the canonical SF repo.

https://packagist.org/packages/mediawiki/semantic-forms

should be transferred to the normal https://github.com/SemanticMediaWiki account.

Well, why don't you do that? You have the rights to do so, or to create the repo here in the first place.

JeroenDeDauw commented 9 years ago

Naming this "Semantic Bundle" can cause quite some confusion. At the very least the description should start of explaining how this is different from Semantic Bundle.

Personally I'd also be more happy if the existing project got modified and if coordination with @yaronkoren happened (at least if he cares to do so), rather than having two different efforts going on.

Don't get me wrong, I do appreciate the good work being done here!

mwjames commented 9 years ago

Naming this "Semantic Bundle" can cause quite some confusion.

I'm more or less indifferent to the name but the bundle on this account is only concerned with Semantic extensions and has nothing to do with HeaderTabs or ApproveRevs etc. which should be placed in a MediaWiki Bundle or similar.

If you want to call it differently, what should it be?

At the very least the description should start of explaining how this is different from Semantic Bundle.

Well, the current Semantic Bundleis more than a Semantic Bundle it includes other components that do not depend on SMW and mixing non-dependencies with strong-dependencies is rather an odd practice.

Despite this clear difference, I don't expect that other packages will or can provide any unit tests that would allow them to run against different MW/SMW versions. The bundle can only make it to a real bundle where dependencies are specified and packages are actually tested otherwise you create the same situation as of now that incompatibilities are caught after someone has installed the bundle.

This is also the reason why I don't think SF will make into the bundle (unless you have some integration tests) because having Composer support is just not enough (you want to test that it is actually working).

JeroenDeDauw commented 9 years ago

Well, the current Semantic Bundleis more than a Semantic Bundle it includes other components that do not depend on SMW and mixing non-dependencies with strong-dependencies is rather an odd practice.

This is true when defining and distributing bundles is trivial. Semantic Bundle was created before we had Composer support. Indeed, it was created before Composer. I've yet to see a user complain about the other extensions being in there though.

only concerned with Semantic extensions and has nothing to do with HeaderTabs or ApproveRevs etc.

Well, then Semantic Bundle is even more confusing, since that is what people expect when they hear the name. That leaves us with the most obvious name being taken already, but that's history we cannot change.

This is also the reason why I don't think SF will make into the bundle

I agree it'd be much better if SF has some tests. However, since it does not have any real amount, is it really to the users benefit to exclude it? Tests or not, it's a very useful extension, and it's not totally broken, as bugs get found and fixed by other (granted, less efficient) means. Semantic Bundle has been there for years, without such compat tests, and incompatibility bugs have never really been a problem.

If you want to call it differently, what should it be?

  • SemanticAwesomeness
  • AllTheSemantics
  • SemanticBundlePlus
  • MediaWikiUsefullnessBundle
  • MWJamesApprovedExtensionsThatCanBeInstalledViaComposerAndHaveTests

How about something like SmartWikiBundle? People at SMWCon always talk about how Semantic is not good for marketing, with Smart being a much better alternative. The same goes for MediaWiki/Wiki, though if you go with something like SmartCollaborationBundle, it sounds really unrelated to SMW.

mwjames commented 9 years ago

@SemanticMediaWiki/testers I'm calling for input on possible suggestions for names if we want to provide a "bundle" of semantic extensions that can be easily tested together and updated using Composer (under the assumption that Semantic Bundle is already taken).

mwjames commented 9 years ago

MWJamesApprovedExtensionsThatCanBeInstalledViaComposerAndHaveTests

Nice name a bit long but I don't think anyone needs my approval, I'm just sick and tired of people running into problems when trying to update SB with Composer just to realize it won't work and then having trouble to return to a path where something does work.

In short, I want that you modify the composer.json (which takes about 30 sec) submit the PR, run the tests (which hopefully pass if not you are in big trouble), press the release button and done with it. The only thing that a user has to do is to run the composer update command.

JeroenDeDauw commented 9 years ago

You might get confused people doing something like

{
    'mediawiki/semantic-bundle': '2.0',
    'mediawiki/semantic-media-wiki': '~2.1',
}
mwjames commented 9 years ago

You might get confused people doing something like

Composer will give a warning if things can't be resolved, it is the job of the dependency manager to bring that to a users attention.

JeroenDeDauw commented 9 years ago

Sure, just pointing out this is something certain users will run into and be confused by. (And the Composer error message is probably not going to unconfuse them.) When I was thinking about creating composer based bundles, I imagined using normal version ranges, rather than specific versions. If you do that, and bundle 2.0 requires SMW ~2.0 rather than 2.0, then the example provided will not result in a conflict.

mwjames commented 9 years ago

I agree it'd be much better if SF has some tests. However, since it does not have any real amount, is it really to the users benefit to exclude it? Tests or not, it's a very useful extension, and it's not totally broken, as bugs get found and fixed by other (granted, less efficient) means. Semantic Bundle has been there for years, without such compat tests, and incompatibility bugs have never really been a problem.

The point is that if we want to switch to third-party libraries (Ask, DataValues, DBAL etc.) sooner or later established structures will break and having a platform to easily check and verify that before it is deployed is of more importance (in my mind) than to have a component added to the "bundle" just for the sake of the component without real benefit for the bundle, the user, or the component itself.

Of course, you are always able to do a composer require ... but it won't be tested with the other components in the bundle and therefore you can't be sure that it is actually working. Having something added to the bundle without being able to test it would just defy the idea of being a stable package (and I remember the orig. SB had some components that did some include something which broke because files no longer existed or moved).

How about something like SmartWikiBundle? People at SMWCon always talk about how Semantic is not good for marketing,

I think this is not really a problem of the name but rather shows that users are still looking for a more workable definition of what SMW can and can't do and they are confused as to where and what it can be used for. A name alone will not solve this mystery and using an even more ambiguous naming scheme will surely not help the cause.

The first rule in marketing is to occupy the mind of a potential consumer by using easily identifiable names and patterns that are repeated over the course of an engagement. As of now Semantic (in connection with MediaWiki) is the one part that uniquely identifies a component of being a member in the SMW category.

with Smart being a much better alternative. The same goes for

  • SmartBundle (this is a real stretch but "smart" as in to use queries to answer questions more broadly)
  • SemanticSmarty
  • SemanticPackage (keep the core name to be easily identifiable and categorizable of its nature)
  • SemanticBridge (bridge as in building a more complete path to the outer world)
  • SemanticBasket (as in a basket full of apples, bananas etc.)
  • SemanticCompound (no idea ...)
  • SemanticSolemn (as in to do serious business with SMW)
  • SemanticCommons (recognize notability of relevant packages, ah well no idea, just dropping names)
  • SemanticLollipop (if above are not good enough)

When I was thinking about creating composer based bundles, I imagined using normal version ranges, rather than specific versions. If you do that, and bundle 2.0 requires SMW ~2.0 rather than 2.0, then the example provided will not result in a conflict.

Whichever works best (range, distinct), I just wanted to kick-off and get it done so that the base is available instead of waiting of something to be happen on its own.

kghbln commented 9 years ago

I am not really a fan of clever and smart when it comes to wikis. I'd rather stick with something semantic. Further ideas I can come up with are SemanticComposerBundle (here people may directly see that they have to use Composer, however it may confuse them when they are also seeking for other extra extensions which are included in the classic bundle like HeaderTabs etc.) or SemanticExtensionSuite which may also be a nice "marketing" name or just SemanticSuite though I prefer having extension in the name.

plegault3397 commented 9 years ago

Semantic Basics

s7eph4n commented 9 years ago
Contrafibularity commented 9 years ago

Semantic Suite is concise and to the point (as in a software suite), more so than generic terms like 'package' or 'collection', and using the term 'suite' may be a nice if subtle musical nod to 'composer'.

You could put either 'Extensions' or 'Composer' in there but not both of them.

s7eph4n commented 9 years ago

:+1:

Although thinking about it, we should not add 'Composer' to the name. Tomorrow we will use something else. To make it somewhat more specific, what about 'Semantic Suite for MediaWiki'?

aeon-rain commented 9 years ago

So if this is a brainstorming session to find a name... ;)

I'd go with something like "Semantic MediaWiki Bundle" or "Semantic Extensions Bundle" or alternatively "... Package".

ckoerner commented 9 years ago

I'm new to all this so I apologize for my ignorance.

My dictionary defines semantic as "relating to meaning in language or logic."

Ok, neither of those are very good. :)

What is the goal of SemanticBundle? Is it to make installation of a hand-picked set of SMW extensions easy to install? Easy to update? Is it intended to be comprehensive?

I see that there is some explanation on the wiki page. Not comprehensive, but a particular 'best practice' for semantic wikis?

I don't use SemanticBundle as it exists now. I'd much prefer to install what I need by hand and select things as we determine they're needed. A blasphemous question, but does bundling extensions do us more good than harm? Are we unique in this approach as compared to other MW initiatives?

Another note: "Semantic Bundle is a suitable alternative if you cannot run Composer". That wouldn't be true if all extensions included were distributed via Composer, which is where things are headed, no?

mwjames commented 9 years ago

What is the goal of SemanticBundle? Is it to make installation of a hand-picked set of SMW extensions easy to install? Easy to update? Is it intended to be comprehensive?

The goal of this package (different from the classic bundle) is to have a concise method to install and update components that are known to work together on the fact that they define a dependency to SMW (or to other components if required) and can be run together in a test environment (that's the important part) to verify that results (specified by the tests) are still as expected and not broken through any recent changes in SMW.

Tests can not prevent failure but increase the likelihood that a component is still working as intended (intended as in expressed by the available tests).

SMW needs to change from a monolith piece of software (that only a few well actually less than a few can maintain) to something that is more versatile (which requires changes) but without necessarily breaking its "eco-system".

I don't use SemanticBundle as it exists now. I'd much prefer to install what I need by hand and select things as we determine they're needed. A blasphemous question, but does bundling extensions do us more good than harm? Are we unique in this approach as compared to other MW initiatives?

This is fine and you can continue to do so but for people that are less likely to dig into the clam on how to administer SMW for various extensions it will be a short-cut and hopefully less likely to create inter-components incompatibilities (as seen with the classic SB).

Think of it as a fruit basket where you get a selection at the doorstep of your local grocery without having to browse the items, check for its inventory or be surprised by a sour apple.

mwjames commented 6 years ago

While there have been some requests in the past about such package the overall opinion is that users can easily combining composer packages of their own. Creating another repository to ease the installation would only increase maintenance work for project members and not create any specific improvements for the overall project.

kghbln commented 4 years ago

Now at https://github.com/SemanticMediaWiki/SemanticBundle