typelevel / discipline Goto Github PK

I've noticed discipline imports scalacheck which then inadvertently leaks upstream as it's not in test scope (not sure about scalatest as I see it optional. Shouldn't it be set as test scope? (this got leaked into the scalajs distro as well which prompted me about it)

[info]     | +-org.typelevel:discipline_2.11:0.4 [S]
[info]     | | +-org.scalacheck:scalacheck_2.11:1.12.4 (evicted by: 1.12.5)
[info]     | | +-org.scalacheck:scalacheck_2.11:1.12.5 [S]

Should there be a discipline-effect using https://github.com/typelevel/scalacheck-effect? If so I'm not sure if it should be a separate repo or included here

Blocked by:

• etorreborre/specs2#735

POM file contains a wrong URL (http://typelevel.org/scalaz).
https://github.com/typelevel/discipline/blame/master/build.sbt#L90
http://search.maven.org/#artifactdetails%7Corg.typelevel%7Cdiscipline_2.11%7C0.3%7Cjar

Discipline is awesome. It's documentation is not.

Opening an issue which may or may not be started at hack the tower day to update the documentation so there's a quickstart for new users.

Another one from Michael: checkAll(monadTests ++ alternativeTest)

This is useful if checking laws for typeclasses belong to the same hiearchy e.g. Monad and Alternative. Running tests for them separately causes common tests to be run twice.

Potential blockers (that I know of):

• typelevel/scalacheck#396

An idea from Michael: .filter(_.id != "...")

This would make it easy to skip tests in certain situations e.g. typelevel/cats#4263

While uTest is not so widely used it is very useful for scala.js projcets

The following straight forward test does not compile with the current version of discipline:

package org.typelevel.discipline
package specs2

import org.specs2.mutable.Specification

class MutableDisciplineSpec extends Specification with Discipline

The error message received is that:

[error]  self-type pellucid.pframe.ColumnAlgebrasSpec does not conform to
 org.typelevel.discipline.specs2.Discipline's selftype 
 org.typelevel.discipline.specs2.Discipline 
 with org.specs2.SpecificationLike

The problem is that mutable provides its own SpecificationLike that does not inherit from the root SpecificationLike, even though it satisfies the interface. This means that replacing the self-type in the definition of the Discipline trait with extension fixes the issue as seen in my pull request. Similarly, replacing the dependency on SpecificationLike with "SpecificationStructure with SpecificationFeatures" would do the trick.

However, I'm not sure whether what is ultimately desirable, here, is a fix to discipline or specs2.

https://repo1.maven.org/maven2/org/typelevel/discipline-core_3/1.5.0/discipline-core_3-1.5.0.pom

<scm>
  <url>https://github.com/vasilmkd/discipline</url>
  <connection>scm:git:https://github.com/vasilmkd/discipline.git</connection>
  <developerConnection>scm:git:[email protected]:vasilmkd/discipline.git</developerConnection>
</scm>

sbt-typelevel plugin issue? 🤔 /cc @armanbilge

https://github.com/typelevel/sbt-typelevel/blob/3eb3f99e21c63d37e902826bae44bac7e45574a1/github/src/main/scala/org/typelevel/sbt/TypelevelGitHubPlugin.scala#L43-L73

It seems the latest version for dotty is not available in scalajs though it shows up on scala 2.13.
Would it be possible to include that combination in a release?

Needed for typelevel/cats#1648

• scalatest/scalatestplus-scalacheck#10

Background: https://gitter.im/non/alleycats?at=57625efcdfb1d8aa45a3f9f0

This cant be sent via a PR since it creates a new branch in discipline, but heres the relevant diff:
v0.4...benhutchison:release/0.4.1

When a rule set duplicates ids from a parent ruleset, the rule set's properties are silently dropped in favor of the parent's. This happened twice in Cats (typelevel/cats#3493), both times unwittingly and unintentionally.

The scaladoc requires:

The only requirement here is that ''inside one kind'', the identifier of a property is unique, since duplicates are eliminated.

We could offer an idCollisions: Set[String] on the RuleSet, and leave it up to the test integrations to fail when non-empty, but this would be a breaking change. Alternatively, we could deduplicate with an obnoxious suffix instead of silently dropping duplicate properties, which should be safe unless people are relying on this deduplication. I don't think they should be for anything but optimization, and Discipline's most prominent client, Cats, was bitten by the current behavior.

There are some nice new features in 1.14.0 (for example, displaying/setting test seed), but it is binary incompatible with the previous version. This means that Discipline using 1.13.5 prevents us from using the current versions of both ScalaCheck and Specs2.

Hi,
As I see everything is ready for discipline to be published for Scala.js 1.0.0-RC2
Let's do it?

Thanks!

Would it be possible to get a release for scala 2.11.0-M1 and M2?

will be needed before cats can publish, I think

Required dependencies:

• scalacheck_2.12.0-M4
• specs2-core_2.12.0-M4

At this point ScalaCheck is on 1.12.2, ScalaTest is on 2.2.4, and Specs2 is on 3.6.

It would be great to update the dependencies and do a new release, to avoid getting too out-of-date.

We're seeing NoSuchMethodError with

[error]   org.typelevel.discipline.specs2.mutable.Discipline.$anonfun$checkAll$1(Discipline.scala:17)
[error]   org.specs2.specification.core.Fragments$.$anonfun$foreach$1(Fragments.scala:144)
[error]   scala.collection.LinearSeqOptimized.foldLeft(LinearSeqOptimized.scala:126)
[error]   scala.collection.LinearSeqOptimized.foldLeft$(LinearSeqOptimized.scala:122)
[error]   scala.collection.immutable.List.foldLeft(List.scala:89)
[error]   org.specs2.specification.core.Fragments$.foreach(Fragments.scala:144)
[error]   org.typelevel.discipline.specs2.mutable.Discipline.checkAll(Discipline.scala:16)

probably due to a old dependency on scalacheck-specs2 in discipline 0.10. Would a 0.11 release be possible?

Not sure what happened, but for 1.0.3, the release command only released the Scala Native version, where it should've released all artifacts.

Just curious - I tried compiling for 2.11, tests pass, everything seems to work.

Would it be possible for a 2.11 artifact to be published to the official repos? I'm trying to upgrade Breeze to 2.11, Breeze depends on Spire and Spire in turn depends on Discipline.

We can do this ourselves if necessary, but it seems better not to if we can avoid it.

As a working example, discipline could provide an "AnyRefLaws" implementation that checks the behavior of the default equals and hashCode methods.

In particular, the implementation could work from:

• a makeClone method that creates a deep copy of an instance,
• two particular instances that are guaranteed to compare as != with differing hashCode.

See for example: https://github.com/denisrosset/alasc/blob/master/scalacheck-binding/src/main/scala/net.alasc/laws/AnyRefLaws.scala

I'd gladly provide a PR if there is interest.

Now that we have scala.js support in master, it would be great to get a release out there.

@larsrh, are you happy with the current state of master? Do you think it is releasable as-is?