Hey, the easypost extension is largely broken, we have fully restored it but it seems like that it’s not realistic to make a PR against the current version. The changes where immensely complex as multiple iterations of Solidus as well as Easypost APIs had to be skipped. We have no intention of doing all incremental steps of solidus but would make the current version available. Changes: • The extension also supports inbound and outbound shipments now • products can be configured for reverse economy (I buy instead of selling), the feature can also be fully ignored • shipment methods can be created manually now (before only automatically) • tresholds for shipment co pay for remote areas is supported (if shipping costs less than x make free, otherwise x €) Do you people want it as an extension?

Yes, I'm sure that would be valuable.

Is there anything i am missing about people being so crazy about shipstation? Are there particular features that easypost doesn’t have?

I am using ShipEngine (ShipStation API) on a project and it's pretty similar to EasyPost. There are some differences when it comes to support for return labels, I think EasyPost is a bit better. In terms of outgoing carrier list, it's pretty similar. Also both have APIs for address validation etc, so I think it's probably comes down to cost/carrier support.

EasyPost has softer t-shirts.

BTW: easypost is all ounces and inches, is there any setting we need to consider?

Solidus makes no assumptions about what units you use for values like "weight" because core Solidus doesn't do anything with those values.

Is that something we want to keep that way?

There are issues with changing it, but it's really a matter of whether core needs to care about the units.

It’s a question of giving imperatives in my opinion: • easypost needs conversion • ship station needs the unit I don’t see how we can warrant localisation without it. We either need to set it inside the the extension or inside solidus. As units are universal I would set it inside core. If we give currency and language I don’t see why we shouldn’t give units.

Tons of stores already have data in these fields with the units that they've chosen. Making it possible to configure the extension with the units chosen is much less disruptive.

I somehow always struggle with this argument that tons of stores do it, we shouldn’t offer a default for it, I think solidus should give stronger imperatives. How can languages, states and currencies be important, but weight units are not? All our shipping integrations have a weight unit component when creating a label. I am sorry, but I strongly disagree, let’s find a way to let the extensions lean on the core and not the core leaning on extension or customization in frontend regarding something like units. If you think about it the unit where ever needed would need to be hardcoded in • shipping extensions • Frontends to display weight and measurements across as many pdp as you have (smarter people would probably invoke just one component) In addition people could just ignore it!

How can languages, states and currencies be important, but weight units are not?

Weight units are important because many stores make assumptions about them. I see negative value in trying to mandate everyone use the same units. Unless someone else on core disagrees, we are not changing this. Assume the units in your extension and make that explicit in the README or make it a configurable option.

Could you share some use cases outside • metrical • imperial US • imperial UK

I don't know of any.

Is there any way you feel we could break it down on those + metrical and offer those as a configuration option inside products for dimensions and weight? I am not saying we should throw imperial away, I am saying we should offer options.