Casey Jao

Since users are already accustomed to managing software using dnf/yum, and in fact will have to continue using that tool in their `toolbox` environments, wouldn't it make sense for rpm-ostree...

Hi @mshkanth, V11 doesn't yet differentiate between functional and non-functional electrons in its electron count. Actually, while parameter electrons require no processing, the other electron types, indicated by `electron_dict_prefix` or...

Even the patch in #754 wouldn't help here. All I do there is replace `Electron.__getattr__` with [the user-defined electron](https://github.com/AgnostiqHQ/covalent/pull/754/files#diff-19420ec90ca8d41f533ddfd395a0af8c44b23b1a067cc04cf0968d518de42108R261) ```python @ct.electron def getattr(e, attr): return getattr(e, attr) ``` That works...

For the time being, I agree with @scottwn that the defining a custom electron like ```python def append(array, x): array.append(x) return array ``` would be a workaround. However, this would...

A related problem is that we currently don't support Electrons that return a Callable.

Hi @mshkanth, when Covalent runs an electron, it computes its inputs from the transport graph -- @FyzHsn's comment >Electron inputs are actually computed during run time - it's not something...

For a given electron, its incoming edges are labeled with the type of argument ("arg", "kwarg"), the parameter name, and the parameter order in the case of args.

Please also keep in mind that all electron inputs are encoded, and you should not attempt to decode them. Instead, access their string representations via `TransportableObject.object_string`.

@mshkanth Yes, that should work.

Dask has special handling for Torch Tensors and other popular data structures: https://github.com/dask/distributed/tree/177dfb891089cc872bab34fb8369d75cae13bc0a/distributed/protocol We may need to extend cloudpickle similarly. See also [this issue](https://github.com/dask/distributed/issues/2581)